From owner-freebsd-arch@FreeBSD.ORG Mon Aug 23 23:43:28 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 BD3271065672 for ; Mon, 23 Aug 2010 23:43:28 +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 A2F968FC1D for ; Mon, 23 Aug 2010 23:43:28 +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 <0L7M00M0SPW42K70@asmtp024.mac.com> for freebsd-arch@FreeBSD.org; Mon, 23 Aug 2010 16:43:17 -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-1008230203 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-08-23_08:2010-08-24, 2010-08-23, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: <20100823.171201.107001114053031707.imp@bsdimp.com> Date: Mon, 23 Aug 2010 16:43:15 -0700 Message-id: <8C76250B-E272-4807-BD0D-9F50D0BC5E10@mac.com> References: <20100823.171201.107001114053031707.imp@bsdimp.com> To: "M. Warner Losh" 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: Mon, 23 Aug 2010 23:43:28 -0000 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. > And how do you emulate the mount_foo programs for > foo filesystems? Some of them do weird things that might not > translate well into the kernel... True. I haven't flushed that out, but I was hoping that nmount(2) would have normalized most of this that it's a non-issue, provided we support mount options in this scheme. If you have a concrete example of something that's not so trivial, but critical to support, let me know and I'll take it into account. > As you can see, I'm torn about how I feel about the idea. For simple > cases, I think it is great, but as complexity builds, I become less > sure. What if that iso image was compressed? Can you elaborate how this is potentially a problem in this scheme, but not for "manual" mounting? > What if I had a > software RAID of disks or flash devices? I see no problem. In fact, the idea is triggered by switching to a flash file system on a NAND flash. > What about crypto? See above. Can you elaborate? > I know I > can handle those cases in /bin/sh, but will each new one require more > code in the kernel? The way I see it is that the approach enhances how we now mount the root file system. We have very limited flexibility. I do not claim that my idea allows every possible variation, and I think it unfair to expect that of the approach. If one has real complex requirements, one can always just mount some file system on some storage device and deal with the root mount in user space. I don't see how this prevents that. > What would df and/or mount tell you about the > now-hidden file systems? Can you explain what you mean by now-hidden file systems? Thanks, -- Marcel Moolenaar xcllnt@mac.com