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

[Olaf Hering]

 On Wed, Sep 15, H. Peter Anvin wrote:

> Olaf Hering wrote:
> > On Tue, Sep 14, christophe varoqui wrote:
> >
> >
> >>Putting it this way, it seems the initrd is the right place for stuff
> >>like lvm2, multipath, mdadm ... but I'd like to be sure before dropping
> >>the provisional klibc support in the tools.
> >
> >
> >I would like to see a way to construct a general purpose initramfs image
> >that fits everyones need. It should also be part of the normal kernel
> >build process.
> 
> "Everyone's" need is extremely broad.

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.



-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG