[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