[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]