On Fri, 15 Dec 2000, Werner Almesberger wrote:
> 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 ?
Just out of curiosity, what would happen with redirection if your source
tree for 'the currently running kernel' version happens to be configured
for a different 'the currently running kernel', perhaps a machine of a
foreign arch that you are cross-compiling for?
I do this: I use ONE machine to compile kernels for five: four i386 and
one SUN4C. My other machines don't even HAVE /usr/src/linux, so where does
this redirection leave them?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
