Re: Adding functions to libutil, part 2

[mlelstv%serpens.de@localhost (Michael van Elst)]

reinoud%netbsd.org@localhost (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).