From owner-freebsd-arch@FreeBSD.ORG Tue Aug 24 01:24:37 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 A8FBA1065693 for ; Tue, 24 Aug 2010 01:24:37 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 8D48C8FC0A for ; Tue, 24 Aug 2010 01:24:37 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from sa-nc-cs-125.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp024.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L7M0055ZUK7VJ10@asmtp024.mac.com> for freebsd-arch@FreeBSD.org; Mon, 23 Aug 2010 18:24:09 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1008230219 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-08-23_09:2010-08-24, 2010-08-23, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: <20100824002350.042A45B3B@mail.bitblocks.com> Date: Mon, 23 Aug 2010 18:24:07 -0700 Message-id: <4CB9F7C8-39E8-4C3B-A3F8-A5A9EC178E7D@mac.com> References: <20100823.171201.107001114053031707.imp@bsdimp.com> <8C76250B-E272-4807-BD0D-9F50D0BC5E10@mac.com> <20100824002350.042A45B3B@mail.bitblocks.com> To: Bakul Shah X-Mailer: Apple Mail (2.1081) 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 01:24:37 -0000 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