I propose to fix some recent breakage in libutil's opendisk(3).
The changes to the device pathname rewriting may be ok, but
the change in the interpretation of the iscooked parameter has
broken things left and right.

Previously, iscooked specified how to rewrite the device name into
a pathname if the pathname didn't open directly. (Perhaps in an
abstract sense it also specified a device type to open, but it
would cheerfully open whatever pathname was passed to it, so it
really didn't have any such meaning in practice.)

Now, it definitely specifies a type check and the file is closed
and the call errors out if anything other than a block device was
opened with iscooked true, or a char device with iscooked false.
The man page has been updated to specify this, too.

The results of this change have been, at least:

	bin/14468: pcictl(8) is broken by a change to opendisk(3)
	that constrains iscooked=1 to block devices (uwe@netbsd.org)

	4 of the 7 Makefile's under distrib/alpha broke, some in
	multiple places

	disklabel(8) and vnconfig(8) have had half of their legal
	invocations suddenly made to error out, because they _used_
	to work on either the block or the char device, but now
	they must pick one and the other errors out. (I believe
	disklabel(8) is hard enough to use without arbitrarily
	withdrawing half of its formerly accepted command space.)

	no utility that uses opendisk(3) can now work on a plain
	file. Working on plain files is important at times when
	preparing bootable images under sys/.../stand/ or src/distrib/.

The results of this change may also include:

	break various scripts in the field which use disklabel(8),
	vnconfig(8), scsictl(8), atactl(8), or pcictl(8)

	breaking sysinst, by causing some of its disklabel(8) commands
	to error out

	breaking other port's distrib/<arch> directories

The only reason supplied for making this change was: to produce an
ever-so-slightly better error message for the case that disklabel(8)
is run on a plain file. That can be accomplished, and with a much
more meaningful message, by fixing the problem directly. (I.e., inside
disklabel(8).)

I have agreed with the author that the interface has problems: perhaps
it needs a wildcard or a bit mask for specifying file types. However,
the first thing it needs is to have the existing published interface
unbroken.

	r.o.s.s