On Sat, Dec 02, 2006 at 09:37:18PM -0500, Trond Myklebust wrote: > On Sat, 2006-12-02 at 23:55 +0100, Willy Tarreau wrote: > > I'm not saying initramfs is not powerful, and indeed your example is > > the common way of parsing cmdline for me too. What I'm saying is that > > before nfsroot stops being supported, we'll need a working replacement > > (and not "### further parse $arg"), if possible within the kernel tree > > so that people who used to build kernels to boot such machines will > > still be able to build kernels for them, even if this implies using > > an initramfs with some tools in it. > > > > The real danger of removing support for in-kernel features like this > > is to leave people with no solution at all (because they don't know > > how to proceed), and their workarounds are often worse than the > > problem that we tried to fix in the first place. > > It hasn't been removed yet. However most distributions choose not to > enable it because that would force them to compile the NFS client into > the main kernel instead of leaving it as a module.
That's a valid point, but in fact, building with NFS client and serial port support in the kernel on some archs is as common as building with IDE driver and VGA console in the kernel on x86. With some architectures used in light networked workstations, it's very common to boot from the network (sparc & parisc come to mind, sorry to those I forgot), hence this common practise. > As for the initramfs support, hpa has assured me that his klibc > distribution already has a full solution for NFS mounting on current > kernels. That's again where we see the limits of this ever-developping 2.6. I'm not saying that doing this from initramfs+tools is a bad solution, since it solves lots of problems, it's just that it is *much* different from what was previously done. People who have installed a distro on their machines will not be able to upgrade their kernel past a certain point by hand. Upgrading distro packages in such environments is generally not always an option (particularly boot packages such as boot loader and kernel), because the boot server is not necessarily running on the same OS/distro, and sometimes the kernel needs different build options. Then the remaining solution to get stability and security fixes is often to [cross-]compile a more recent kernel, and to put it on the boot server. Fortunately Adrian maintains 2.6.16 :-/ > Trond Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
