On Wed, Jun 4, 2008 at 11:21 PM, Nicolas Williams <Nicolas.Williams at sun.com> wrote: > On Wed, Jun 04, 2008 at 10:46:08PM -0500, Mike Gerdts wrote: >> 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? > > When we run into such issues we tend to move the relevant library into > /lib (leaving behind a symlink in /usr/lib).
My only concern with this approach is that it adds a bit of bloat to ramdisk images. libfstyp in turn dynamically loads per-fstype shared libraries and as such libfstyp should remain relatively small (currently 19K). > mount(1M) long predates fstyp(1M) and libfstyp. That's the more likely > explanation. Understood. > But, too, what should mount/fstyp do with things like NFS or CIFS URLs > (which needn't be URLs either)? Or "swap"? > > (Well, the answer is likely: return "nfs," "cifs" or "tmpfs" if it can > unambiguously tell, else return an error and let the user tell mount > what the fs type is.) nfs seems to be already handled, for server:/path and nfs://server/path I think the right thing to do for cifs is to consider a device that starts with // (but not //dev/?) is cifs. A dusty memory of mine is telling me the POSIX says that multiple /'s in a row must be treated as equivalent to a singe /, with the exception that at the beginning of the path multiple /'s can have a special meaning. Handling smb URL's should certainly be done. tmpfs is an odd enough case that I'm not so sure that it is worth worrying about. I suppose if the device is "swap" it would be easy enough to tell it to mount a tmpfs file system. However mount_tmpfs(1M) is clear that the "special" (device) argument is ignored. zfs could be tricky. Currently "fstyp /dev/dsk/c1t0d0s4" says it is zfs. That doesn't mean that I can mount c1t0d0s4 anywhere. fstyp(1M) fails to tell me that it is zfs if I ask it about a dataset. -- Mike Gerdts http://mgerdts.blogspot.com/
