tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Adding functions to libutil, part 2



Hi Michael, thanks for your feedback,

On Fri, Jun 21, 2024 at 06:24:53AM -0000, Michael van Elst wrote:
> 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().

As its precursor blockcheck(), in sbin/fsck/fsutils.c it uses all these
functions from libutil to get to the end result and iterating when needed. And
indeed its ROOT.x :) that was a typo from me and all handled by
getfsspecname() anyway.

> >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.

If they were never intended to be used separately then shouldn't they be in
libexec?

> 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).

That is an omission stemming from the time only FFS was around IMHO; for
othogonality we could split them one day if someone is bored enough...

> We also have 'df' where 'df -W' prints the original symbolic path
> (but just for NAME=) because a resolved symbol path cannot be
> reversed.

'df -W' just uses getmntinfo() and mount(8) only calls getfsspecname() before
passing it on. The rest is for the mount programs to figure out. The fsck(8)
uses its blockcheck() function to preparse everything before it then passes it
to the relevant fsck_* program. This new function is nothing more as a generic
subtitute of that functionality and decouple it from fsck specific things like
perr() etc.

> I fear your one-size-fits-all function just grows the zoo of interfaces
> (and its results is by no means 'canonical' either).

That name grew as its meant to be the place to support all forms of device
specifications in one place and from the optional extra possible functionality
(not yet implemented) that it looks up its resulting st_rdev in /dev/ so if
for whatever reason a device node is symlinked or used elsewhere it will
always return the same one in /dev/. Bit esotheric maybe but people can do
strange things with fstabs, softlinks or bluntly hardlinking.

One of the ideas that seem to be behind the origional blockcheck() and thus
also canonical_rdev() is just that; to get some sanity in the zoo of functions
and to support all the possible name specifications that all have their
separate functions in libutil in one place; its to glue all these libutil
functions together.

If used together with an enhanced getdiskinfo() (see part 1) that fabricates
geometry for files all tools will automatically gain the posibility to work on
files too but maybe thats a bit off topic and a bridge to far for now. I've
done simular things for all udf tools too as i needed to emulate specific
device types in makefs anyway and the actual code doing the works has no idea
its writing to a file instead of a device.

Does this make sense for you?

With regards,
Reinoud



Home | Main Index | Thread Index | Old Index