[ On Monday, June 16, 2003 at 23:20:03 (+0200), Manuel Bouyer wrote: ]
> Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
>
> On Mon, Jun 16, 2003 at 04:57:21PM -0400, Greg A. Woods wrote:
> > 
> > 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).
> 
> Not at all. The error message is clear: "Operation not supported by device"

You cannot take the phrase used in the NetBSD sys_siglist alone and out
of context.  Error codes are specified in Standards, such as POSIX
1003.1-2001, which says:

     [ENODEV]
             No such device.

You also have to consider the specific definition of the error code
w.r.t. to the system call in question.

ENODEV is not mentioned explicitly as a valid error code for open(2),
but that shouldn't stop us from choosing a better error code for a tape
drive with no tape in it, if indeed that's the way the tape drivers are
going to continue to work.

Note POSIX doesn't clearly define ENODEV for ioctl(2) on non-STREAMs
devices, though it does suggest that "operation" has to do with the
ioctl() command request, not the state or capability of the underlying
hardware:

     [ENODEV]
             The fildes argument refers to a valid STREAMS device, but
             the corresponding device driver does not support the
             ioctl() function.

There's also somewhat conflicting advice w.r.t. the ioctl() command
request in the specification for ioctl(2):

     [EINVAL]
             The request or arg argument is not valid for this device.

In any case nothing here indicates that ENODEV should be used to
represent the state of the underlying hardware.


> For inexistent devices the error is ENXIO "Device not configured"

Indeed things have changed somewhat since unix had simple device switch
tables which were indexed directly by the device file node major number.

This does not condone the re-use of ENODEV for less critical problems.

Indeed it doesn't really justify the change in the use and meaning of of
ENXIO either.  It is defined in POSIX, and always was since V7:

     [ENXIO]
             No such device or address.

Unfortunately POSIX has also somewhat re-defined ENXIO for open(2):

     [ENXIO]
             The named file is a character special or block special
             file, and the device associated with this special file does
             not exist.

and, FYI, for ioctl(2) as well:

     [ENXIO]
             The request and arg arguments are valid for this device
             driver, but the service requested cannot be performed on
             this particular sub-device.

> Trying to read an empty drive is inappropriate as well.

read(2), perhaps, but not ioctl(2).


> Not in the current state of hardware

The state of the hardware should have nothing to do with what operations
the driver generically supports, and so even if ENODEV keeps it's
non-standard definition in NetBSD, it's still not the right error code
to use to represent a normal condition of the underlying hardware.

Note if you read the specific SCSI tape driver documentation for other
UNIX variants you'll find descriptions like this for MTIOCGET:

    MTIOCGET

	Returns status information about the tape drive.  The mt_type
	field is set to the appropriate value defined in <sys/mtio.h>.
	Bits in the mt_dsreg field are set to indicate whetehr the tape
	is write protected or if the drive is offline.  NOTE:  If there
	is no tape in the drive it is considered to be both offline and
	write-protected.

> I agree that ENXIO is far too confusing for this. ENOSPC isn't right either,
> as it's limited to removable devices that hold datas.

Hmmm, yes, just like tape drives!  They are devices with removable media
that holds data.

(perhaps you ment NON-removable?  -- in which case you're making far too
many assumptions and leaps of logic....)

In any case POSIX says only:

     [ENOSPC]
             No space left on device.

and like I said there's certainly no space on any tape drive with no
tape inserted in it.

(I'd rather have open() work on any empty drive and ioctl(MTIOCGET) work
as described above, but that's a lot more code to change....)

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