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
