On Mon, Jun 16, 2003 at 04:57:21PM -0400, Greg A. Woods wrote:
> > 
> > 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.

No, at last sd and cd too

> 
> 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"
For inexistent devices the error is ENXIO "Device not configured"

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

Trying to read an empty drive is inappropriate as well.
I can't see anything wrong with returning this error for operations that
are temporarely innapropriate

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

Not in the current state of hardware

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

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. We can immagine
removable devices which don't hold data (I'm sure someone will find an
example :)

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

Why ?

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

This is a documentation bug

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--