[klibc] initrd / initramfs future
H. Peter Anvin
hpa at zytor.com
Wed Sep 15 14:35:50 PDT 2004
Olaf Hering wrote:
>
> I doubt there are that many different types of 'root filesystem on $foo'.
>
> Is this list complete?
> root on plain partition (on whatever physical medium)
> root on lvm volume
> root on software raidN
> root on evms
> root on lvm/raid combination (however that works)
> root on nfs
> root on iscsi
> root on some hardware raid (I bet it requires additional bianries)
>
> My '/init' script can handle it all, except evms and hardware raid.
> Thats easy to fix, if you beat me to it.
> That, + basic udev and module-init-tools, and we have a generic solution
> for 'mount the root filesystem'.
>
> Really, I doubt your plan to 'just put klibc into kernel source' is a
> good plan, unless you intend to do all the above.
> Ideally, put klibc in, together with the tools to moun the root
> filesystem on the things mentioned above. But where will it end?
>
> It would be even better if that is an own project which is intergrated
> into kbuild. How does it work today:
> You just grab your kernel from kernel.org, build and boot it, even in
> the crosscompiled case.
> Once the stuff behind prepare_namespace() is removed, some external help
> is required because you cant just download, build and boot it anymore.
>
OK... now I'm confused. Your paragraphs 2 and 3 seem to directly
contradict each other. Are you saying it should or should not be part
of the kernel tarball?
For the time being, my main concern has been to get a compatibility
platform off the ground so we can do gradual migration of functionality.
This means dropping something into the kernel tree which supports all
current functionality, in a compatible fashion (sometimes the hard
part!) but has at least some of that functionality implemented in
userspace -- nfsroot being the obvious choice.
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.)
- Should I continue down the compatibility route, and gradually migrate
your functionality into that solution?
- Should we do the compatiblity thing, but really recommend that people
use the standalone solution?
- Should we try to do the "big bang" type patch which does everything
coming out the chute?
-hpa
More information about the klibc
mailing list