On Mon, Jun 16, 2003 at 07:40:36PM -0400, Greg A. Woods wrote:
> [ 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.

Solaris and Linux define it that way, so maybe we should change it.
But then it's redundant with ENXIO, and we need something else for
"Operation not supported by device" (maybe use EOPNOTSUPP ?)

This require a large audit, because ENODEV is used in many parts of the system

> 
> 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 it's not forbidden either

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

In case of ioctl. We're talking about others system calls here (open,
in this case)

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

Nothing prevent it either


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

Which is a bit too long for an error message :)

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

We're talking about open() here


> 
> 
> > Not in the current state of hardware
> 
> The state of the hardware should have nothing to do with what operations
> the driver generically supports,

Well, my POV is that the operations supported by the driver *depends* on
the state of the hardware.
For example, "eject -l"

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

Maybe EOPNOTSUPP is better. ENOSPC doens't look right, in the sense that
it's confusing:
mt offline
mt: /dev/nrst0: No space left on device

What does the space left on the device has to do with ejecting it ?

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

But again we're talking about open here, not ioctl.

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

No, I meant removable. hot-plug devices are not limited to devices that
hold data. We could have some non-data device where only part of it is
removable, in such a way that the device always probe but isn't always
fully functionnal.

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

there's no tape at all, and I think it should be a different error

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
     NetBSD: 24 ans d'experience feront toujours la difference
--