Re: Linus's include file strategy redux

[Werner Almesberger <Werner.Almesberger@epfl.ch>]

Alexander Viro wrote:
> In the situation above they should have -I<wherever_the_tree_lives>/include
> in CFLAGS. Always had to. No links, no pain in ass, no interference with
> userland compiles.

As long as there's a standard location for "<wherever_the_tree_lives>",
this is fine. In most cases, the tree one expects to find is "roughly
the kernel we're running". Actually, maybe a script to provide the
path would be even better (*). Such a script could also complain if
there's an obvious problem.

I think there are three possible directions wrt visibility of kernel
headers:

 - non at all - anything that needs kernel headers needs to provide them
   itself
 - kernel-specific extentions only; libc is self-contained, but user
   space can get items from .../include/linux (the current glibc
   approach)
 - share as much as possible; libc relies on kernel for "standard"
   definitions (the libc5 approach, and also reasonably feasible
   today)

My personal preference is the third direction, because it simplifies the
deployment of new "standard" elements, and changes to existing interfaces.
The first direction would effectively discourage any new interfaces or
changes to existing ones, while the second direction allows at least a
moderate amount of flexibility for kernel-specific interfaces. In my
experiments with newlib, I was largely able to use the third approach.

I don't want to re-open the discussion on which way is better for glibc,
but I think we can agree that "clean" kernel headers are always a good
idea.

So we get at least the following levels of visibility:

 0) kernel-internal interfaces; should only be visible to "base" kernel
 1) public kernel interfaces; should be visible to modules (exposing
    type 0 interfaces to modules may create ways to undermine the GPL)
 2) interfaces to kernel-specific user space tools (modutils, mount,
    etc.); should be visible to user space that really wants them
 3) interface to common non-POSIX extensions (BSD system calls, etc.);
    should be visible to user space on request, or on an opt-out basis
 4) interfaces to POSIX elements (e.g. struct stat, mode_t); should be
    visible unconditionally (**)

Distinguishing level 0 and 1 is always a little difficult. It seems
that a "kmodcc" that inserts the necessary flags would be useful there
(*). There needs to be a clear distinction between level 1 and 2 (the
current #ifdef __KERNEL__). This boundary could certainly be improved
be moving user-space-visible header files to a separate directory.

Levels 2, 3, and 4 are more difficult to separate, because the people
who know what should go where are not always the ones writing the
kernel headers. Perhaps some more input from libc hackers could help.

(*) Crude examples for such scripts (for newlib): newlib-flags and
    newlib-cc in
    ftp://icaftp.epfl.ch/pub/people/almesber/misc/newlib-linux/
      newlib-linux-20.tar.gz

(**) Multiple versions of the interface can be a problem here, e.g.
     struct oldold_utsname vs. struct old_utsname vs.
     struct new_utsname. It would be nice to have them prefixed at
     least with __. Maybe a __LATEST_utsname macro would be useful
     too ;-) (I know, breaks binary compatibility, hence the
     smiley.)

So ... what's the opinion on slowly introducing a redirection via
scripts ?

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/