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?
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.
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 ...
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 <uapi/linux/coda.h>
#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 ...
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.
also, does all of this make the command:
$ make headers_install
obsolete? because it's still there, doing *something*. is there a
writeup on this that would clarify how this was designed? thanks.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
On Thu, Oct 25, 2012 at 11:46 AM, Robert P. J. Day
[off-list ref] 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 <uapi/linux/coda.h>
#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
On Thu, 25 Oct 2012, Luis R. Rodriguez wrote:
On Thu, Oct 25, 2012 at 11:46 AM, Robert P. J. Day
quoted
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.
quoted
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
========================================================================
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
========================================================================