Re: puzzled by a couple things related to "uapi"

[Robert P. J. Day]

On Thu, 25 Oct 2012, Luis R. Rodriguez wrote:

> Read this guy as well:
>
> http://lwn.net/Articles/507794/

  ah, that's *precisely* the sort of thing i was after, thanks.  i
really should read lwn more often.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: puzzled by a couple things related to "uapi"

[Robert P. J. Day]

On Thu, 25 Oct 2012, Luis R. Rodriguez wrote:

> On Thu, Oct 25, 2012 at 11:46 AM, Robert P. J. Day

> >   ok, so far, so good.  but then there's this in
> > include/uapi/linux/coda.h:
> >
> > ... snip ...
> > #ifdef KERNEL<--- ?
> > typedef unsigned long u_long;
> > typedef unsigned int u_int;
> > typedef unsigned short u_short;
> > typedef u_long ino_t;
> > typedef u_long dev_t;
> > typedef void * caddr_t;
> > ... snip ...
>
> Interesting, not sure. David ? I do see some BSD'ish deps there  (#if
> defined(__NetBSD__))... so not sure if that was left to them or what.
>
> >   why is there still kernel-only content in the uapi/ directory?
> > maybe i just don't understand the rationale for what's going on here.
>
> No, I'm as puzzled.

  there's quite a lot of that sort of thing ... i just did this for
the heck of it:

$ cd include/uapi
$ grep -r "if.*KERNEL" *

and you can see for yourself.

  and i'm still unclear on what the point of "make headers_install" is
anymore, since it does still exist and appears to do much of what it
did before.  doesn't the whole idea of uapi make that target obsolete?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: puzzled by a couple things related to "uapi"

[Luis R. Rodriguez]

On Thu, Oct 25, 2012 at 11:46 AM, Robert P. J. Day
 wrote:
>
>   looking at the "uapi" reorganization in the kernel source for the
> first time, and a couple things confuse me.
>
>   i see the principle -- collect all the userspace API content in one
> place, in this case include/uapi/.  this obviously(?) is supposed to
> represent a newer way to represent what you got formerly with
>
>   $ make headers_install
>
> that is, header files identified in Kbuild files, cleansed of any
> kernel-only content, then placed under usr/include in the source tree.
> is that about right -- is that what it's supposed to represent?

Read this guy as well:

http://lwn.net/Articles/507794/

So avoiding issues with double dependency is really another objective.

>   so at a *guess*, it would seem that, if a header file that should be
> part of uapi didn't need any cleaning, it could go straight into
> include/uapi untouched.

Yup.

>   on the other hand, if a header file *did* have some kernel-only
> content, i would have *thought* that there would be two versions of
> that header file:
>
>   a) the one with the kernel-only content still under include/linux,
> which would turn around and, in some way, include ..

It includes the respective uapi header as well.

>   b) the common content file under include/uapi
>
>   does that make sense?  because i took a quick look and here's an
> example i don't understand.  there's include/linux/coda.h, with the
> contents:
>
> #if defined(__linux__)
> typedef unsigned long long u_quad_t;
> #else
> #endif
> #include 
> #endif
>
>   ok, so far, so good.  but then there's this in
> include/uapi/linux/coda.h:
>
> ... snip ...
> #ifdef KERNEL<--- ?
> typedef unsigned long u_long;
> typedef unsigned int u_int;
> typedef unsigned short u_short;
> typedef u_long ino_t;
> typedef u_long dev_t;
> typedef void * caddr_t;
> ... snip ...

Interesting, not sure. David ? I do see some BSD'ish deps there  (#if
defined(__NetBSD__))... so not sure if that was left to them or what.

>   why is there still kernel-only content in the uapi/ directory?
> maybe i just don't understand the rationale for what's going on here.

No, I'm as puzzled.

  Luis

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies