[klibc] Re: klibc structure in the kernel
sam at ravnborg.org
Sat Jul 31 00:08:39 PDT 2004
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
> 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
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.
More information about the klibc