[ On Monday, June 16, 2003 at 21:28:58 (+0200), Manuel Bouyer wrote: ]
> Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
>
> On Mon, Jun 16, 2003 at 02:22:45PM -0400, Greg A. Woods wrote:
> >
> > The first is that if tape is empty the driver returns ENODEV on open of
> > a non-control device (i.e. a device node without both low bits set (11)
> > in the minor number).  I think the patch I offered in the initial PR
> > mostly solves this problem.
> 
> I don't see why you think ENODEV isn't right here. This is what other drivers
> return when there's no media too.

Then I would say the other (tape?) drivers are broken as well.

ENODEV suggests that device does not exist or that there's no driver
configured for it (or more rarely that the driver doesn't have a
function for the related system call).

Traditionally (in V7), and as per the NetBSD intro(2), ENODEV is
supposed to indicate "An attempt was made to apply an inappropriate
function to a device, for example, trying to read a write-only device
such as a printer." (or conversely I suppose trying to write to a
read-only device such as a CD-ROM).  This happened because in V7 ENODEV
was returned by a stub function whenever a device driver had no
associated function to be placed in the block or character device switch
tables, including when there was no device driver available at all for a
given slot in the tables.  As far as I can see there were no other uses
of ENODEV in V7.  Anyone who has managed any Unix for more than a few
years, and particularly if they've managed more than one type of Unix,
will have come to know ENODEV as a very bad thing that indicates kernel
configuration problems or hardware problems (at least whenever you know
that the error should not have happened :-).

In *BSD I suppose it could be argued that the associate error string for
ENODEV suggests the ioctl(2) command request) is not supported by the
driver, where as in this case it clearly is a supported operation.
However traditionally (in V7) unsupported ioctl() requests usually
resulted in ENOTTY (or occasionally in ENXIO), and indeed that's clearly
the meaning given by the error string associated with ENODEV.

Traditionally (V7) ENXIO was used when drives are empty:

	I/O on a special file refers to a subdevice that does not exist,
	or beyond the limits of the device.  It may also occur when, for
	example, a tape drive is not dialled in or no disk pack is
	loaded on a drive.

I think ENOSPC is far better than ENXIO in this case since it suggests
only that the device is "out of space", which is effectively true when
there's no tape in it.  All the other errors suggest there's something
wrong with either the device or the driver or the kernel config.

In any case modern (NetBSD) drivers should not be returning ENODEV only
some of the time and only because of the state of the hardware.  (Note
also that ENODEV is not documented as a valid error code in any tape or
SCSI-related driver manual pages, nor in any driver-related system
calls.)

BTW, as for the worry Ben expressed that changing this error code could
cause compatability problems with tape-device using applications, I
would suggest that's not very likely and indeed almost impossible in
this case.  Some applications do make fine-grained decisions based on
some error codes, but never (as far as I've ever seen or can find now)
on either of these two particular error codes, and also normally never
when the system call is open(2).

Personally I don't think ioctl(st_4_dev, MTIOCGET, ...) should ever fail
so long as the kenel is correctly configured and the drive is
responding, but that's perhaps a separate and larger issue.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>