[klibc] initrd / initramfs future
H. Peter Anvin
hpa at zytor.com
Wed Sep 15 15:24:28 PDT 2004
Olaf Hering wrote:
> prepare_namespace does more, you would need something like /sbin/udev to
> create the current device nodes. The kernel must be buildable by a user,
> so mknod will not work. Having the special case for /dev/console is
> certainly ok, but for more device nodes like /dev/hdaN?
We can make gencpio or whatever it's called take a list of special
device nodes, somewhat similar to the way rpm handles it. I'm not too
worried about that one aspect.
>>What you have done above seems like a lot more abitious; this is a good
>>thing because it gives more of a concrete benefit. What I'm not clear
>>on is what you're suggesting:
>>- Should be drop the idea of putting it into the kernel and maintain it
>>as a separate project forever? (Not that that isn't a legitimate option.)
> For a start it is probably ok, but its already legacy when it hits
> kernel.org. People will scream if you remove klibc again, I'm sure :)
> Better check if doing an external project in the first place is better,
> for whatever reason.
OK... this sounds like something which probably should be discussed on
LKML or in some other forum, since I think a bunch of the people who
need to be involved aren't on this list. Personally I'm not at all
opposed to klibc standalone; it's been relatively easy to maintain that
way, but I think some people (including Linus) would object to the
kernel tarball not being independently bootable. Perhaps I'm wrong.
More information about the klibc