I've long been annoyed by the fact that mount(1M) isn't smart enough
to figure out the file system type but fstyp(1M) is. As I was writing
the code to fix this annoyance, I found the reason why.
# ldd mount
libfstyp.so.1 => /usr/lib/libfstyp.so.1
libnvpair.so.1 => /lib/libnvpair.so.1
libc.so.1 => /lib/libc.so.1
libnsl.so.1 => /lib/libnsl.so.1
...
Is the dependency on a library in /usr the only reason that such a
change would be problematic? If so, would using dlopen() be an
acceptable method for loading the library only if it is needed?
The approach that I am taking is to use an option to specifiy that
mount should "figure it out".
# ./mount -f /dev/lofi/2 /mnt
# grep /dev/lofi/2 /etc/mnttab
/dev/lofi/2 /mnt hsfs ro,noglobal,maplcase,rr,traildot,dev=24c0002 1212586417
As such, it would be easy to use dlopen() and dlsym() to get the
necessary fstyp_* functions only if the -f option is specified.
FWIW, the -f optin is currently in use by what appears to be dead
code.
393 if (fflg) {
394 if ((strcmp(farg, "S51K") != 0) &&
395 (strcmp(farg, "S52K") != 0)) {
396 fstype = farg;
397 }
398 else
399 fstype = "ufs";
400 } else /* if (Fflg) */
401 fstype = Farg;
In my search to figure out what S51K and S52K are, I ran across:
6661055 usr/src/uts/common/sys/fsid.h should die or brought up to date
My initial approach is to take over the -f option and would probably
whack 6661055 while I am at it. Changes (still with /usr dependency)
can be seen at http://cr.opensolaris.org/~mgerdts/mount/.
Are there issues I'm not aware of that make this not worth working on?
If not, am I right in assuming that fasttrack will be required?
--
Mike Gerdts
http://mgerdts.blogspot.com/
