Date: Tue, 24 Aug 2010 08:52:05 -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: <20100824155205.C2A535B23@mail.bitblocks.com> In-Reply-To: Your message of "Tue, 24 Aug 2010 07:56:08 PDT." <760A97A4-62D2-4900-915D-CA5D889855E1@mac.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> <4CB9F7C8-39E8-4C3B-A3F8-A5A9EC178E7D@mac.com> <20100824043344.CA4DE5B56@mail.bitblocks.com> <760A97A4-62D2-4900-915D-CA5D889855E1@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 24 Aug 2010 07:56:08 PDT Marcel Moolenaar <xcllnt@mac.com> wrote: > > On Aug 23, 2010, at 9:33 PM, Bakul Shah wrote: > > > On Mon, 23 Aug 2010 18:24:07 PDT Marcel Moolenaar <xcllnt@mac.com> wrote: > >> > >> 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!). > > > > BTW, a friend tells me this is what Linux does (or more > > likely, what they used in their server startup). > > I see your point and buy into the argument, but not > entirely. I explicitly mentioned "embedding" and so > far your arguments include things like GENERIC being > 10MB or Linux server startup. > > We're not exactly discussing the same thing are we? This friend's company used linux in an embedded system [it was a fileserver product. Presumably the OS had to run in a restricted environment since the FS space would be for their customers' use + you don't want to have to reload the OS when a disk dies! And yet you want the ability to upgrade your OS s/w etc.] In my job[-2] we used FreeBSD as an embedded OS. IIRC we just ran from a readonly flash FS as root. An upgrade was just a new FS image, including kernel + utilities. Didn't Juniper do something similar? > I'm perfectly happy to say that the ramdisk approach > is the most generic and solution for desktop and > server machines but I'm not at all ready to have it > include embedded systems just yet. It's just too > heavy weight... I would argue that while each individual embedded system typically runs in a simpler environment than GENERIC, the sum total of such embedded environments presents a large set of alternatives. Now if you can distill all that down to a small set of kernel changes, that is great! But I am not doing the work, you are. So feel free to use/ignore my input however you wish!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100824155205.C2A535B23>