On Wed, Sep 15, H. Peter Anvin wrote: > 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? Distros have to use the same stuff, and installing the kernel-sources just to get the initramfs image done isnt the brightest idea. Thats the reason why having an external project 'which does it all' is a better choice. > 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. prepare_namespace does more, you would need something like /sbin/udev to create the current device nodes. The kernel must be buildable by a user, so mknod will not work. Having the special case for /dev/console is certainly ok, but for more device nodes like /dev/hdaN? > 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.) For a start it is probably ok, but its already legacy when it hits kernel.org. People will scream if you remove klibc again, I'm sure :) Better check if doing an external project in the first place is better, for whatever reason. > - Should I continue down the compatibility route, and gradually migrate > your functionality into that solution? It depends, if klibc itself becomes that solution? I havent thought about it that much. > - 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? Maybe we should first define what is needed, beside the current klibc functionality (shell + tools, ipconfig, nfsmount, mount): /sbin/udev to generate devnodes on the fly inside the initramfs module handling uuid + label handling libdevmapper lvm software raid evms "that hardware raid stuff" Too bad, having all these tools as static klibc binaries will duplicate much tools. To pick one random example: If you upgrade evms, the klibc version should be updated as well. Will evms provide its own way to build also a klibc binary? If yes, it should probably a static one. If klibc gets updated, the klibc-$foo.so interpreter will change $foo, and the just built evms tools will not run anymore. Or, a copy of some evms release is shipped inside klibc. I havent followed the lvm, evms and devicemapper stuff, how incompatible are the different releases? I see a device-mapper-1.00.09 on my workstation. If 1.00 is a stable interface, no problem. If there are subtle differences between 1.00.09 and 1.00.42, it would be a minor problem. Maybe there can be a distro-wide mkinitramfs project. It would get us closer to the day where prepare_namespace() is removed from the kernel. I see, that looks already like a fun project... -- USB is for mice, FireWire is for men! sUse lINUX ag, n�NBERG