[dm-devel] Re: [klibc] initrd / initramfs future

["H. Peter Anvin" <hpa zytor com>]

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.

	-hpa