[klibc] Re: klibc structure in the kernel

H. Peter Anvin hpa at zytor.com
Fri Jul 30 15:13:47 PDT 2004


Sam Ravnborg wrote:
> 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?
> 

Make it usr/klibc.  I was thinking of an older proposal.  As you 
probably can tell, I have no strong preference.

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

I think usr/lib is perfectly unambigious -- after all, that's why the 
usr/ directory -- but let's stick with klibc; as you say, it's 
well-established.

	-hpa



More information about the klibc mailing list