From owner-freebsd-arch@FreeBSD.ORG Tue Aug 24 00:23:51 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 44FBF10657CA for ; Tue, 24 Aug 2010 00:23:51 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 28CE68FC0A for ; Tue, 24 Aug 2010 00:23:50 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 042A45B3B; Mon, 23 Aug 2010 17:23:49 -0700 (PDT) To: Marcel Moolenaar In-reply-to: Your message of "Mon, 23 Aug 2010 16:43:15 PDT." <8C76250B-E272-4807-BD0D-9F50D0BC5E10@mac.com> References: <20100823.171201.107001114053031707.imp@bsdimp.com> <8C76250B-E272-4807-BD0D-9F50D0BC5E10@mac.com> Comments: In-reply-to Marcel Moolenaar message dated "Mon, 23 Aug 2010 16:43:15 -0700." Date: Mon, 23 Aug 2010 17:23:49 -0700 From: Bakul Shah Message-Id: <20100824002350.042A45B3B@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 00:23:51 -0000 On Mon, 23 Aug 2010 16:43:15 PDT Marcel Moolenaar 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!).