From owner-freebsd-arch@FreeBSD.ORG Tue Aug 24 02:27:26 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 B6501106564A for ; Tue, 24 Aug 2010 02:27:26 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 9B28B8FC08 for ; Tue, 24 Aug 2010 02:27:26 +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 asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L7M00J8DXH3AD00@asmtp026.mac.com> for freebsd-arch@freebsd.org; Mon, 23 Aug 2010 19:27:05 -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-1008230235 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-08-24_01:2010-08-24, 2010-08-23, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: <20100823.181424.646155203640260173.imp@bsdimp.com> Date: Mon, 23 Aug 2010 19:27:03 -0700 Message-id: <9EED1D80-7E2E-4C9E-8608-7CFD5B25214B@mac.com> References: <20100823.171201.107001114053031707.imp@bsdimp.com> <8C76250B-E272-4807-BD0D-9F50D0BC5E10@mac.com> <20100823.181424.646155203640260173.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: Tue, 24 Aug 2010 02:27:26 -0000 On Aug 23, 2010, at 5:14 PM, M. Warner Losh wrote: > : > 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. > > mount_smbfs makes a connection to the remote system to do > authentication presently in mount_smbfs and initializes the smb > context before mounting the file system in the kernel. I don't know > if I'd call this a critical to support feature, but it was the first > "exception" to the rule that jumped into my head so I was curious if > you'd thought about it. smbfs is definitely out of scope :-) > : > 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? > > You'd need a way to stack up different modules, since you'd need > geom_uzip over md0 to make it useful to the cd9660 code. This is a perfect example, actually. I'll think about this in the context of my idea... > init(8) is the show stopper to a pivot root approach, unless you could > tell init that's on the first level and simple to exec /sbin/init to > pickup the new copy, but I don't know how happy that would make the > kernel.. I think a handshake is doable. If all else fails, you simply tell the kernel to always re-exec init when it exits (rather than panicing, which isn't exactly a product-friendly response to init exiting). > and if we had one more layer on nand: > > Filesystem 1024-blocks Used Avail Capacity Mounted on > /dev/nor0 4096 4096 0 110% / > /dev/md0.uzip 16000 16000 0 110% / > /dev/nand0 320000 300000 20000 82% / > > or > > Filesystem 1024-blocks Used Avail Capacity Mounted on > /dev/nor0 4096 4096 0 110% /.old_root/.old_root > /dev/md0.uzip 16000 16000 0 110% /.old_root > /dev/nand0 320000 300000 20000 82% / > > is the question I'm asking... I think it would be: /dev/nor0 /.old_root /dev/md0.uzip /.old_root /dev/nand0 / > Anyway, the fact that we have a decoupled fork/exec really is what > lead me to ask the question. It is useful to run arbitrary code > between the two, even if you usually run the same code... sometimes > you want to be different. I was thinking that this might be the same > way here. But, as you rightly point out, maybe there's too much > complexity in doing that and simpler is better. I'll chew on the geom_uzip example you gave. There's value in allowing the full power of GEOM when doing a root mount. Thanks, -- Marcel Moolenaar xcllnt@mac.com