Date: Mon, 23 Aug 2010 16:43:15 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: "freebsd-arch@FreeBSD.org" <freebsd-arch@FreeBSD.org> Subject: Re: RFC: enhancing the root mount logic Message-ID: <8C76250B-E272-4807-BD0D-9F50D0BC5E10@mac.com> In-Reply-To: <20100823.171201.107001114053031707.imp@bsdimp.com> References: <AFBE2FCA-30A6-4E1D-A964-AC4DC4C843EB@juniper.net> <20100823.171201.107001114053031707.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8C76250B-E272-4807-BD0D-9F50D0BC5E10>