Date: Mon, 23 Aug 2010 17:23:49 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Marcel Moolenaar <xcllnt@mac.com> Cc: "freebsd-arch@FreeBSD.org" <freebsd-arch@FreeBSD.org> Subject: Re: RFC: enhancing the root mount logic Message-ID: <20100824002350.042A45B3B@mail.bitblocks.com> In-Reply-To: Your message of "Mon, 23 Aug 2010 16:43:15 PDT." <8C76250B-E272-4807-BD0D-9F50D0BC5E10@mac.com> References: <AFBE2FCA-30A6-4E1D-A964-AC4DC4C843EB@juniper.net> <20100823.171201.107001114053031707.imp@bsdimp.com> <8C76250B-E272-4807-BD0D-9F50D0BC5E10@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 23 Aug 2010 16:43:15 PDT Marcel Moolenaar <xcllnt@mac.com> wrote: > > On Aug 23, 2010, at 4:12 PM, M. Warner Losh wrote: > > *snip* > > > However, all this scripting sounds a bit like a very simple shell in > > the kernel. What advantages are there to this approach vs having the > > ability to run a simple shell script or executable and "pivot" the root > > to a new location? > > The 2 reasons for doing this in the kernel are: > 1. resiliency against ABI changes. > 2. allowing /sbin/init to come from the actual root file system. > > Both points are impossible to handle efficiently or correctly if > you need user space support in getting to your actual root file > system. You basically have a catch-22 or bootstrap problem, which > a pure in-kernel solution doesn't have. How about just bundling a small compressed ramfs with the kernel. The kernel unpacks it, uses it as the initial rootfs and runs init from it. A forth/scheme/lua based program wouldn't add more than a % or so (given that the GENERIC kernel is over 10MB now!).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100824002350.042A45B3B>