On Sat, Dec 08, 2001 at 10:58:45AM -0800, Ross Harvey wrote:
> I suppose this isn't a very important issue (netbsd-specific internal
> library interface and all that) but could you expand on the reason
> for this additional check?
> 
> I'm sure I'm just missing a perfectly good reason for doing it,
> but at first glance it seems like it just takes some calls that
> were about to succeed and errors them out.

If the caller of opendisk(3) specifically wanted a BLK (iscooked != 0)
or CHR (iscooked = 0), then I saw no problem in enforcing that requirement
in opendisk(3) to ensure that the caller obtains a file descriptor of the
appropriate type. In hindsight, I should have had those checks in the code
when I first implemented opendisk(3) over four years ago.

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 also improved the way that the rules for testing the variants of the
argument (e.g, 'wd0' -> 'wd0d', `/dev/rwd0', `/dev/rwd0d').


> E.g. (and ok, sure, one should really let opendisk(3) find the raw
> partition pathname) the following _used_ to work and now fails:
> 
> 	vnconfig /dev/vnd2c ...

Well, vnconfig was asking for a character device from opendisk(3) and
you gave it the block one...


There is possibly merit for creating a more general `opendevice(3)'
API, with a flags argument (rather than just `iscooked') which would
allow control over parameters such as:
	- do the `helpful' name translation
	- if no `/' is present in path, immediately prepend /dev
	  (thus avoiding the `file in current directory of device
	  name' issue)
	- enforce blk semantics
	- enforce chr semantics
	- enforce blk or chr semantics (accept either)

I'm sure there's other functionality that's required. However, at the
time I didn't feel inclined to get into another API debate, and
there was only one program (pcictl ?) that was abusing opendisk(3)'s
previous lack of file type checking anyway. If we find a long-term
need for this, we can revisit opendevice(3) and reimplement
opendisk(3) in terms of that.


Luke.