NetBSD Problem Report #21503
Received: (qmail 11190 invoked by uid 605); 8 May 2003 19:56:05 -0000
Message-Id: <m19DrUZ-000B3kC@proven.weird.com>
Date: Thu, 8 May 2003 15:55:47 -0400 (EDT)
From: woods@weird.com (Greg A. Woods)
Sender: gnats-bugs-owner@netbsd.org
Reply-To: woods@planix.com (Greg A. Woods)
To: gnats-bugs@gnats.netbsd.org
Subject: empty SCSI tape drives cannot be queried or configured
X-Send-Pr-Version: 3.95
>Number: 21503
>Category: kern
>Synopsis: empty SCSI tape drives cannot be queried or configured
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu May 08 19:57:01 +0000 2003
>Closed-Date:
>Last-Modified: Tue Jun 17 16:51:01 +0000 2003
>Originator: Greg A. Woods
>Release: 2003/05/07
>Organization:
Planix, Inc.; Toronto, Ontario; Canada
>Environment:
System: NetBSD-current
>Description:
Empty SCSI tape drives cannot be interacted with using any of
commands which open their raw character device files, but which
do not need media to do their job (e.g. status queries,
configuration controls, etc.)
>How-To-Repeat:
Install a new tape drive in a machine and try checking it and
then wonder yet again why "mt status" and even "scsictl
identify" say "Operation not supported by device"
>Fix:
This isn't a fix -- it's a quick hack to make the resulting
error have a slightly more intuitive meaning. ENODEV is a scary
message, especially when you're simply testing to see if a drive
is correctly identified. ENOSPC is much more intuitive because
obviously there's no space on a drive with no media. ENODEV,
and even the phrase "operation not supported" have entirely
different and more serious meanings to anyone even vaguely
familiar with UNIX devices.
I don't know if a "real" fix is possible or not, though it
should be possible since the drive will obviously respond
properly to an IDENTIFY command as otherwise the kernel wouldn't
be able to probe and attatch it at boot time if it were empty.
If NetBSD had a CAM SCSI subsystem then maybe it would have a
pass(4) device like that in FreeBSD, and maybe it would allow
these operations to be performed even while the drive is empty,
yet retain the existing special behaviour for st(4) (but with
this more intuitively meaningful error, please!).
Index: scsipi_base.c
===================================================================
RCS file: /cvs/master/m-NetBSD/main/src/sys/dev/scsipi/scsipi_base.c,v
retrieving revision 1.88
diff -c -r1.88 scsipi_base.c
*** scsipi_base.c 19 Apr 2003 19:12:59 -0000 1.88
--- scsipi_base.c 8 May 2003 19:33:19 -0000
***************
*** 861,868 ****
periph->periph_flags &= ~PERIPH_MEDIA_LOADED;
if ((xs->xs_control & XS_CTL_IGNORE_NOT_READY) != 0)
return (0);
! if (sense->add_sense_code == 0x3A) {
! error = ENODEV; /* Medium not present */
if (xs->xs_control & XS_CTL_SILENT_NODEV)
return (error);
} else
--- 861,868 ----
periph->periph_flags &= ~PERIPH_MEDIA_LOADED;
if ((xs->xs_control & XS_CTL_IGNORE_NOT_READY) != 0)
return (0);
! if (sense->add_sense_code == 0x3A) { /* XXX MAGIC #!!! */
! error = ENOSPC; /* Medium not present */
if (xs->xs_control & XS_CTL_SILENT_NODEV)
return (error);
} else
>Release-Note:
>Audit-Trail:
From: Ben Harris <bjh21@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org
Subject: kern/21503: empty SCSI tape drives cannot be queried or configured
Date: Thu, 8 May 2003 23:41:08 +0100 (BST)
I can't reproduce this bug on my SCSI tape drive:
viking:~# uname -a
NetBSD viking 1.6 NetBSD 1.6 (VIKING) #0: Wed Oct 30 01:15:29 GMT 2002 bjh21@viking:/usr/src/sys/arch/macppc/compile/VIKING macppc
viking:~# grep ^st0 /var/run/dmesg.boot
st0 at scsibus0 target 4 lun 0: <HP, T4000s, 1.10> SCSI2 1/sequential removable
st0: rogue, drive empty
st0: async, 8-bit transfers
viking:~# scsictl /dev/enrst0 identify
/dev/enrst0: scsibus0 target 4 lun 0 <HP, T4000s, 1.10>
viking:~# mt -f /dev/enrst0 status
SCSI tape drive, residual=0
ds=0
er=2<>
blocksize: 0 (0, 0, 0, 0)
density: 0 (69, 69, 69, 69)
current file number: 0
current block number: 0
I've just checked, and there's no tape in it. It's possible that either
my tape drive's weird, or that this bug has crept in since 1.6, of course.
The fact that "mt" uses /dev/nrst0 as its default device, rather than
/dev/enrst0, is probably worthy of a PR of its own, anyway.
I think that changing error numbers from historical practice, especially
in areas where applications are likely to depend on them (and I suspect
some applications depend on getting ENODEV when they try to open an empty
tape drive) is a bad idea, though.
--
Ben Harris <bjh21@netbsd.org>
Portmaster, NetBSD/acorn26 <URL:http://www.netbsd.org/Ports/acorn26/>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
To: "Greg A. Woods" <woods@planix.com>
Cc: gnats-bugs@gnats.netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
Date: Wed, 14 May 2003 14:53:56 +0200
On Thu, May 08, 2003 at 03:55:47PM -0400, Greg A. Woods wrote:
>
> >Number: 21503
> >Category: kern
> >Synopsis: empty SCSI tape drives cannot be queried or configured
> >Confidential: no
> >Severity: serious
> >Priority: medium
> >Responsible: kern-bug-people
> >State: open
> >Class: sw-bug
> >Submitter-Id: net
> >Arrival-Date: Thu May 08 19:57:01 UTC 2003
> >Closed-Date:
> >Last-Modified:
> >Originator: Greg A. Woods
> >Release: 2003/05/07
> >Organization:
> Planix, Inc.; Toronto, Ontario; Canada
> >Environment:
> System: NetBSD-current
> >Description:
>
> Empty SCSI tape drives cannot be interacted with using any of
> commands which open their raw character device files, but which
> do not need media to do their job (e.g. status queries,
> configuration controls, etc.)
>
> >How-To-Repeat:
>
> Install a new tape drive in a machine and try checking it and
> then wonder yet again why "mt status" and even "scsictl
> identify" say "Operation not supported by device"
Did you try mt -f /dev/enrst0 status ? This work for me, on a DLT7000
--
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr
NetBSD: 24 ans d'experience feront toujours la difference
--
From: "Greg A. Woods" <woods@weird.com>
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
Cc: gnats-bugs@gnats.netbsd.org (NetBSD GNATS submissions and followups),
netbsd-bugs@NetBSD.ORG (NetBSD Bugs and PR posting List)
Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
Date: Mon, 16 Jun 2003 14:22:45 -0400 (EDT)
[ On Wednesday, May 14, 2003 at 14:53:56 (+0200), Manuel Bouyer wrote: ]
> Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
>
> Did you try mt -f /dev/enrst0 status ? This work for me, on a DLT7000
OK, so to finally get back to this PR.
Yes, /dev/enrst0 does work.
I think there are two related problems (well, three or four if you
include the documentation fixes).
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. A good technical documentation editor might
be able to make the st(4) documentation a little better too -- e.g.
remind the reader more prominently that the control mode device must be
used if there's no media in the drive.
The second problem is that 'mt' was never fixed to use the control mode
device by default when that mode was first introduced. That fix can be
done quite simply with the following patch:
Index: src/include/paths.h
===================================================================
RCS file: /cvs/master/m-NetBSD/main/src/include/paths.h,v
retrieving revision 1.22
diff -c -c -r1.22 paths.h
*** paths.h 3 May 2003 03:24:01 -0000 1.22
--- paths.h 16 Jun 2003 18:14:10 -0000
***************
*** 61,67 ****
#define _PATH_CLOCKCTL "/dev/clockctl"
#define _PATH_CONSOLE "/dev/console"
#define _PATH_CSHELL "/bin/csh"
! #define _PATH_DEFTAPE "/dev/nrst0"
#define _PATH_DEVDB "/var/run/dev.db"
#define _PATH_DEVNULL "/dev/null"
#define _PATH_DRUM "/dev/drum"
--- 61,67 ----
#define _PATH_CLOCKCTL "/dev/clockctl"
#define _PATH_CONSOLE "/dev/console"
#define _PATH_CSHELL "/bin/csh"
! #define _PATH_DEFTAPE "/dev/enrst0"
#define _PATH_DEVDB "/var/run/dev.db"
#define _PATH_DEVNULL "/dev/null"
#define _PATH_DRUM "/dev/drum"
Index: src/bin/mt/mt.1
===================================================================
RCS file: /cvs/master/m-NetBSD/main/src/bin/mt/mt.1,v
retrieving revision 1.32
diff -c -c -r1.32 mt.1
*** mt.1 25 Feb 2003 10:34:39 -0000 1.32
--- mt.1 16 Jun 2003 18:17:19 -0000
***************
*** 171,178 ****
.Ev TAPE
is not set, then
.Nm
! uses the device
! .Pa /dev/nrst0 .
.Sh EXIT STATUS
.Nm
returns a 0 exit status when the operation(s) were successful,
--- 171,178 ----
.Ev TAPE
is not set, then
.Nm
! uses the control-mode device for the first SCSI tape:
! .Pa /dev/enrst0 .
.Sh EXIT STATUS
.Nm
returns a 0 exit status when the operation(s) were successful,
(I have several more changes for mt.1 to update the density code table,
but I should probably send those as a sparate PR).
--
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>
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>,
NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Cc:
Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
Date: Mon, 16 Jun 2003 21:28:58 +0200
On Mon, Jun 16, 2003 at 02:22:45PM -0400, Greg A. Woods wrote:
> [ On Wednesday, May 14, 2003 at 14:53:56 (+0200), Manuel Bouyer wrote: ]
> > Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
> >
> > Did you try mt -f /dev/enrst0 status ? This work for me, on a DLT7000
>
> OK, so to finally get back to this PR.
>
> Yes, /dev/enrst0 does work.
>
> I think there are two related problems (well, three or four if you
> include the documentation fixes).
>
> 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.
> A good technical documentation editor might
> be able to make the st(4) documentation a little better too -- e.g.
> remind the reader more prominently that the control mode device must be
> used if there's no media in the drive.
>
> The second problem is that 'mt' was never fixed to use the control mode
> device by default when that mode was first introduced. That fix can be
> done quite simply with the following patch:
I'll let someone else handle this; I don't know what others differences there
are between nrst and enrst ...
--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 24 ans d'experience feront toujours la difference
--
From: Matthew Jacob <mjacob@feral.com>
To: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>
Cc:
Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
Date: Mon, 16 Jun 2003 13:27:30 -0700 (PDT)
2nd time- with correct address.
I don't see why you can't make enrst0 the default.
On Mon, 16 Jun 2003, Manuel Bouyer wrote:
> On Mon, Jun 16, 2003 at 02:22:45PM -0400, Greg A. Woods wrote:
> > [ On Wednesday, May 14, 2003 at 14:53:56 (+0200), Manuel Bouyer wrote: ]
> > > Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
> > >
> > > Did you try mt -f /dev/enrst0 status ? This work for me, on a DLT7000
> >
> > OK, so to finally get back to this PR.
> >
> > Yes, /dev/enrst0 does work.
> >
> > I think there are two related problems (well, three or four if you
> > include the documentation fixes).
> >
> > 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.
>
> > A good technical documentation editor might
> > be able to make the st(4) documentation a little better too -- e.g.
> > remind the reader more prominently that the control mode device must be
> > used if there's no media in the drive.
> >
> > The second problem is that 'mt' was never fixed to use the control mode
> > device by default when that mode was first introduced. That fix can be
> > done quite simply with the following patch:
>
> I'll let someone else handle this; I don't know what others differences there
> are between nrst and enrst ...
>
> --
> Manuel Bouyer <bouyer@antioche.eu.org>
> NetBSD: 24 ans d'experience feront toujours la difference
> --
>
From: "Greg A. Woods" <woods@weird.com>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>,
NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
Date: Mon, 16 Jun 2003 16:57:21 -0400 (EDT)
[ 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>
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>,
NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Cc:
Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
Date: Mon, 16 Jun 2003 23:20:03 +0200
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
--
From: "Greg A. Woods" <woods@weird.com>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>,
NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
Date: Mon, 16 Jun 2003 19:40:36 -0400 (EDT)
[ 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>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
To: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>,
NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Cc:
Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
Date: Tue, 17 Jun 2003 13:44:15 +0200
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
--
From: "Greg A. Woods" <woods@weird.com>
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
Cc: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>,
NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
Date: Tue, 17 Jun 2003 12:50:11 -0400 (EDT)
[ On Tuesday, June 17, 2003 at 13:44:15 (+0200), Manuel Bouyer wrote: ]
> Subject: Re: kern/21503: empty SCSI tape drives cannot be queried or configured
>
> Solaris and Linux define it that way, so maybe we should change it.
Well, yes. :-)
> But then it's redundant with ENXIO
Not to the POSIX definition of ENXIO, which is subtly different.
Traditionally ENODEV suggests you've got a /dev/foo but no driver
installed in the device switch tables for that major number. The full
POSIX "generic" definition (in the "Error Number" section, as opposed to
the English message given in "errno.h") is:
[ENODEV]
No such device. 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.
In POSIX ENXIO on open() means you've got the driver, but no hardware.
That's also the way *BSD generally (though perhaps not 100%
consistently) uses ENXIO as well, at least for open(2). For reference
again the full POSIX definition of ENXIO is:
[ENXIO]
No such device or address. Input or output on a special file
refers to a device that does not exist, or makes a request
beyond the capabilities of the device. It may also occur
when, for example, a tape drive is not on-line.
I.e. for open(2) ENODEV means "no device driver", and for other system
calls it means "no device driver function in the device switch table".
(note also that opening a removable-media device with no media is not
really beyond the capabilities of the device -- only reading from it or
writing to it would be, i.e. the open() should succeed but read() or
write() should return ENXIO)
I remember being confounded over the wording of ENODEV's error message
back in V7 and after learning the true meaning I wished then that the
word "driver" had been appended. However over the years since I've
simply come to translated it automatically as I read it.
> and we need something else for
> "Operation not supported by device" (maybe use EOPNOTSUPP ?)
That's already there and it's called "ENOTTY" (at least for ioctl() --
it makes no sense for open() anyway). The POSIX-defined string is:
[ENOTTY]
Inappropriate I/O control operation.
EOPNOTSUPP has been socket-only for quite a while, and POSIX also strongly
suggests it's only for sockets too:
[EOPNOTSUPP]
Operation not supported on socket. The type of socket
(address family or protocol) does not support the requested
operation.
EOPNOTSUPP might be OK for an ioctl() requesting a rewind operation on a
specific type of device that can't rewind but via a driver that also
does support rewindable devices (e.g. an old 8-track audio loop tape :-),
but I can't conceive of any valid use for EOPNOTSUPP from open(2).
> This require a large audit, because ENODEV is used in many parts of the system
195 occurences in -current's kernel source (not counting compat/*). :-)
(22 of those are in arch/*/stand code and may even be POSIX-compatible uses)
Most should probably be converted directly to ENXIO, and certainly all
that are in the path of any open(2), but some others may need further
thought.
> > 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
I should hope not. :-)
But POSIX does have a quite different suggested meaning for open(),
i.e. it should not indicate anything to do with the state of the
underlying hardware.
> In case of ioctl. We're talking about others system calls here (open,
> in this case)
Well yes -- unless you buy into my bigger suggestion that open() should
succeed even when there's no tape (e.g. as it does for floppies).
> 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 ?
You need to have a slightly more relaxed view of what "no space" means! :-)
Note that we're talking about open() here, not write(). :-)
ENOSPC would definitely be wrong for read() or write() with no media,
but ENXIO would be OK.
> No, I meant removable. hot-plug devices are not limited to devices that
> hold data.
Ah! OK, yes, hot-pluggable devices! (which can also be removable media
devices too! :-)
> 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 the case of a hot-pluggable storage device then the correct error to
return from open(2) when it's suddenly not there any more is ENXIO.
> there's no tape at all, and I think it should be a different error
Strictly I think there should be no error when opening a removable media
device when there's no media in the device -- the open() and any
status-reporting ioctl() should all work, with or without media.
--
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>
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home