Re: CVS commit: basesrc/lib/libutil

[Luke Mewburn <lukem%wasabisystems.com@localhost>]

On Sat, Dec 08, 2001 at 07:05:55PM -0800, R.o.s.s  H.a.r.v.e.y wrote:
> But the caller may be able to operate on _either_ class of device.
> This is the case with vnconfig(8) and disklabel(8).  Plus, at times
> we have wanted to run some utilities on plain files without using
> vnd(4), but now they must bypass opendisk(3).

opendisk(3) never supported a `wildcard' "iscooked" (as you call it.)
Previously it just never enforced the BLK/CHR semantics.


> > This changes the user visible behaviour from:
> >     % echo "foo" > wd0
> >     % disklabel wd0
> >     disklabel: can't read master boot record: Undefined error: 0
> > to:
> >     % echo "foo" > wd0
> >     % disklabel wd0
> >     disklabel: wd0: Operation not supported by device
> > (although wd0 could be in `...' to make it more obvious)
> 
> I certainly see the need for a better error message from disklabel(8),
> but I'm not impressed by the improvement; a far better message
> would have resulted from directly improving disklabel(8).
> 
> Changing the opendisk(3) API from `iscooked specifies optional
> rewriting' to the current meaning seems like a severe and indirect
> way of fixing disklabel(8).

I didn't change the API from `iscooked specifies optional rewriting'.
I just enhanced the type checking.

In the following examples, I'll use "wd0" as the path, and "d" as
the raw partition (getrawpartition()+"a").  Previously, opendisk(3)
with iscooked==0 would try opening (in order, until open(3) returns 0,
or -1 && errno != ENOENT):
        wd0, wd0d, /dev/rwd0, /dev/rwd0d
(i.e, the raw/char devices).  With iscooked!=0, it would try:
        wd0, wd0d, /dev/wd0, /dev/wd0d
(i.e, the cooked/block devices) 

The last two variants in either case were not tried if there is a `/'
in the path.

The current version does this, but ensures that the type of device
opened on a successful open(3) matches that specified by opendisk(3).


Granted, the opendisk(3) API was, (and still is), deficient in that it
doesn't provide `open either block or char' semantics, even though it
did not enforce it previously. Thus my comment about an enhanced
opendevice(3) API to replace it.