[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100905062207.GA31275@merkur.ravnborg.org>
Date: Sun, 5 Sep 2010 08:22:07 +0200
From: Sam Ravnborg <sam@...nborg.org>
To: Andres Salomon <dilinger@...ued.net>
Cc: devicetree-discuss@...ts.ozlabs.org, sparclinux@...r.kernel.org,
x86@...nel.org, tglx@...utronix.de, mingo@...hat.com,
hpa@...or.com, cjb@...top.org, Mitch Bradley <wmb@...top.org>,
pgf@...top.org, linux-kernel@...r.kernel.org, davem@...emloft.net,
grant.likely@...retlab.ca,
Stephen Neuendorffer <stephen.neuendorffer@...inx.com>
Subject: Re: [PATCH 1/9] of: move phandle/ihandle into types.h
On Fri, Sep 03, 2010 at 04:17:15AM -0400, Andres Salomon wrote:
> On Mon, 30 Aug 2010 07:06:27 +0200
> Sam Ravnborg <sam@...nborg.org> wrote:
>
> > On Sun, Aug 29, 2010 at 11:53:52PM -0400, Andres Salomon wrote:
> > >
> > > We need phandle for some exported sparc headers; of.h isn't an
> > > exported header, and it would be silly to export it when all we
> > > really need is one or two types from it. So, move the
> > > phandle/ihandle definitions into types.h.
> > >
> > > diff --git a/include/linux/types.h b/include/linux/types.h
> > > index 01a082f..26526ea 100644
> > > --- a/include/linux/types.h
> > > +++ b/include/linux/types.h
> > > @@ -219,6 +219,10 @@ struct ustat {
> > > char f_fpack[6];
> > > };
> > >
> > > +/* Basic openboot/openfirmware types */
> > > +typedef u32 phandle;
> > > +typedef u32 ihandle;
> > > +
> > > #endif /* __KERNEL__ */
> >
> > The above is inside #ifdef __KERNEL__ / #endif
> > so it is not exported as we drop code protected
> > by __KERNEL__ when we prepare for export.
>
>
>
> At least for me, that's fine; I don't need phandle/ihandle to be
> available to userspace. The folks who work on the userspace fdt code
> may feel differently, however.
>
> (I'm not sure if you're suggesting it be outside the __KERNEL__ ifdef
> or not..)
If the goal is to get ihandle/phandle exported to userspace then
they have to be moved outside __KERNEL__.
I just tried to export sparc64 headers,
and here I found references to ihandle/phandle in a comment
only sparc does not need these types today.
The relevant function took and returns an int btw.
So the above looks good considerign that userspace
so far does not require ihanlde/phandle.
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists