Date: Mon, 23 Aug 2010 18:24:07 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Bakul Shah <bakul@bitblocks.com> Cc: "freebsd-arch@FreeBSD.org" <freebsd-arch@FreeBSD.org> Subject: Re: RFC: enhancing the root mount logic Message-ID: <4CB9F7C8-39E8-4C3B-A3F8-A5A9EC178E7D@mac.com> In-Reply-To: <20100824002350.042A45B3B@mail.bitblocks.com> References: <AFBE2FCA-30A6-4E1D-A964-AC4DC4C843EB@juniper.net> <20100823.171201.107001114053031707.imp@bsdimp.com> <8C76250B-E272-4807-BD0D-9F50D0BC5E10@mac.com> <20100824002350.042A45B3B@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 23, 2010, at 5:23 PM, Bakul Shah wrote:
>> 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!).
Not impossible, but it isn't exactly simpler from what I'm looking
for:
1. The /sbin/init being run is not the one on the actual (final)
root file system. Getting that one to run requires a special
init on the ramdisk.
2. The R/O image needs the underlying file system mounted some-
where so that there's persistent storage to write. Setting
all of this up in user space is impossible if the underlying
file system(s) needs to be unmounted/unmountable.
3. Upgrades and downgrades are tricky to handle when the root
F/S is the ramdisk, after which some user space environment
has to find the storage media and then mount it using mount
options it has no easy way to obtain.
It appears that this solution, while in user space, requires more
code and special handling than a "simple" recursive algorithm for
something the kernel has to do anyway. I may be mistaken though...
--
Marcel Moolenaar
xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CB9F7C8-39E8-4C3B-A3F8-A5A9EC178E7D>