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
