rein...@netbsd.org (Reinoud Zandijk) writes: >that returns a canonical raw device name when passed a device name in one of >the following ways: > /dev/ld0 > name="UUID" > name="ROOT.x" > /dev/dk1 > /some/mountpoint > some/file/name
That looks like many distinct functions to me. 1. resolve a symbolic path (like NAME="") into a device path This is what getfsspec() does. 2. determine the underlying device of a filesystem object. This is what stat() does. 3. determine the raw (character) device name for a device path. This is what getdiskrawname() does. 4. determine the device name for a configured mountpoint (before mounting): This is what getfsfile() does. It doesn't account for just specifying the device name (not path) as supported by many programs through opendisk(). N.B. There is no name="UUID" (it's _the_ wedge name, not a UUID). There is no name="ROOT.x" but just ROOT.x. >The goal is to have a uniform code that accepts all ways to specify a raw >device. Currently every program has its own logic and oddities/omissions like >fsck_ffs does accept files but fsck_msdos only grocks raw devices etc. Actually we have 'mount' which resolves the device name and 'mount_*' that gets passed the resolved name. We have 'fsck' which resolves the device name and 'fsck_*' that gets passed the resolved name. We don't have anything similar for newfs (there is no newfs_ffs). We don't have anything similar for dump (there is no dump_ffs). We don't have anything similar for dumpfs (there is no dumpfs_ffs). We also have 'df' where 'df -W' prints the original symbolic path (but just for NAME=) because a resolved symbol path cannot be reversed. I fear your one-size-fits-all function just grows the zoo of interfaces (and its results is by no means 'canonical' either).