Re: [PATCH 2.6.24] chroot= as a new kernel parameter

[Willy Tarreau <w@1wt.eu>]

On Thu, Mar 06, 2008 at 08:46:21PM +0100, Peter Zijlstra wrote:
> 
> On Thu, 2008-03-06 at 12:53 +0100, Pavel Machek wrote:
> > On Thu 2008-03-06 12:37:29, Ingo Molnar wrote:
> > > 
> > > * Chris Wedgwood <cw@f00f.org> wrote:
> > > 
> > > > > But given an existing initrd (which might have come from the distro, 
> > > > > etc.) i prefer adding boot options instead of modifying the initrd.
> > > > 
> > > > I assume this is so you have have /distro1 /distro2 and use your boot
> > > > option to (help) select which one you boot into?
> > > 
> > > while i have no personal use for chroot=, i generally test distros that 
> > > way, yes - and i try to keep them as unmodified as possible.
> > > 
> > > "Use the initrd as an extended boot commandline" is a poor answer IMO. 
> > > 
> > > _Everything_ we do on the boot commandline that affects user-space can 
> > > be done in an initrd in theory - but still we have hundreds of boot 
> > > options.
> > 
> > Yes, please. chroot= is useful, nonintrusive, and it just should be there.
> 
> As much as I hate initrd, and all features building dependencies on it,
> I don't see the need for either initrd or kernel support for chroot= as
> it can be trivially done using a slightly longer init=.

I don't want to play devil's advocate, but there is clearly *more* bloat
in adding a "chroot" executable in a directory than having a syscall and
boot option in the kernel. Not to mention that the chroot binary must be
replicated into all the available chroots (ok sometimes maybe it can be
achieved using hardlinks).

While I think that the feature does not bring much for mainline distros,
it makes more sense for embedded or rescue systems where init is responsible
for setting the system up, including extraction of libs and binaries (eg:
run busybox --install) or mounting of other filesystems.

Willy