mount(8) in /stand?

[David Schultz]

On Sat, Feb 07, 2009, Ivan Voras wrote:
> 2009/2/7 Giorgos Keramidas <keramida at ceid.upatras.gr>:
> > On Sat, 07 Feb 2009 03:16:46 +0100, Ivan Voras <ivoras at freebsd.org> wrote:
> >> Judging by Google's results I'm only one of many people frustrated by the
> >> lack of mount(8) in the "emergency holographic shell". My problem is that
> >> I have everything I need to install the system (on a "netbook" laptop -
> >> no CD reader) on the USB drive I booted from, but no way to get to the
> >> data (the network drivers need to be patched before they can be used so
> >> net install is out, sysinstall doesn't recognize the directory structure,
> >> has no way of mounting msdosfs, etc.). I see the mount executable is ~~
> >> 17 kB:
> >>
> >> -r-xr-xr-x  1 root  wheel  17232 Dec 29 15:29 /sbin/mount*
> >>
> >> This is about the third time I needed it in similar circumstances so is
> >> probably not unreasonable to request it be crunched in for the future?
> >> It's certainly one of the basic emergency utilities.
> >
> > You have to account for the size of several mount_xxx executables too.
> > My userland is now installed with DEBUG_FLAGS='-g' so the sizes are not as
> > large as they seem below, but we need at least *some* of these to be in
> > `/stand' before `/stand/mount' is usable e.g. for cd9660 mounts:
> 
> What is the relationship between mount and mount_xxx? Is it that some
> file systems cannot be mounted at all if there's no mount_xxx or it's
> just there to provide advanced or unusual options?

Some filesystems have unusual options or require extra magic
(e.g., loading kernel modules). These differences should be
handled by the filesystem kernel code, but they're presently
handled by having N nearly-identical mount_xxx binaries. Craig
Rodrigues probably has a better understanding of what's still
required to fix this.