puzzled by a couple things related to "uapi"

Robert P. J. Day rpjday at crashcourse.ca
Thu Oct 25 14:46:37 EDT 2012


  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
========================================================================



More information about the Kernelnewbies mailing list