[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]