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

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

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