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