From owner-freebsd-arch@FreeBSD.ORG Tue Aug 24 15:52:07 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06BE610656A8 for ; Tue, 24 Aug 2010 15:52:07 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id D3DDB8FC1B for ; Tue, 24 Aug 2010 15:52:06 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id C2A535B23; Tue, 24 Aug 2010 08:52:05 -0700 (PDT) To: Marcel Moolenaar In-reply-to: Your message of "Tue, 24 Aug 2010 07:56:08 PDT." <760A97A4-62D2-4900-915D-CA5D889855E1@mac.com> References: <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> Comments: In-reply-to Marcel Moolenaar message dated "Tue, 24 Aug 2010 07:56:08 -0700." Date: Tue, 24 Aug 2010 08:52:05 -0700 From: Bakul Shah Message-Id: <20100824155205.C2A535B23@mail.bitblocks.com> Cc: "freebsd-arch@FreeBSD.org" Subject: Re: RFC: enhancing the root mount logic X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 15:52:07 -0000 On Tue, 24 Aug 2010 07:56:08 PDT Marcel Moolenaar wrote: > > On Aug 23, 2010, at 9:33 PM, Bakul Shah wrote: > > > On Mon, 23 Aug 2010 18:24:07 PDT Marcel Moolenaar 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!