[klibc] Re: klibc structure in the kernel

[Sam Ravnborg]

On Fri, Jul 30, 2004 at 01:54:12PM -0500, H. Peter Anvin wrote:
> Sam Ravnborg wrote:
> >
> >The linux kernel have traditionally combined files by usage more than
> >by architecture.
> >All architecture specific headerfiles are in include/asm-$(ARCH)
> 
> What's the difference between include/asm-$(ARCH) (vs include/) versus 
> usr/include/arch/$(ARCH) vs usr/include?  The only difference is a slash 
> rather than a dash, and I think the slash makes more sense.

I have no preferences between slash vs dash.
In the end I prefer the dash, more look-alike the kernel.
But please, please no need for a symlink!

> 
> >Many architecture specific drivers are in drivers/..
> >
> >Having all header files in one place also makes it easier to grep them all,
> >Think of this from a user perspective, where the other arch bits are
> >of much less relevance than the headers.
> >
> >A naive user would expect to find all include files in one place,
> >and not hidden somewhere under a directory full of .c files.
> 
> Well, the sick part with the current Linux kernel tree is that it has 
> BOTH...
> 
> I think include/asm-$(ARCH) is a hideously annoying idea; it's really 
> frustrating while editing stuff in arch/$(ARCH).
> 
> That being said, I'm ok with usr/include/arch/$(ARCH) rather than 
> usr/lib/arch/$(ARCH)/include.
      ^^^ ???

So for include files we have:
usr/include/arch-i$(ARCH)/...	<= with no extra include dir

You wrote usr/lib above, but the proposal was to go for usr/klibc.
What do you prefer here?

The proposed klibc name were used for two purposes:
o 'klibc' is a wel established term
o lib/ is used by the kernel for kernel lib files, so no confusion
  added by reusing the lib/ name. lib/ is also used for same purposes
  in the boot specific code for at least ppc.

     Sam