Opening an EIDE CDROM with no disk in the tray yields EIO. Doing the same on a SCSI cdrom yields ENODEV. Returning ENXIO instead of EIO breaks vmware and seems to me, at least, to be the wrong error. There _is_ a device there. Fix: IMHO, the two devices should be consistent, and EIO, at least, doesn't break vmware.
State Changed From-To: open->feedback Is this still the case?
Responsible Changed From-To: freebsd-bugs->freebsd-scsi Over to -scsi since the proposal is to change cd0.
On Thu, Aug 22, 2002 at 12:42:22 -0700, Johan Karlsson wrote: > Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi > Responsible-Changed-By: johan > Responsible-Changed-When: Thu Aug 22 12:40:51 PDT 2002 > Responsible-Changed-Why: > Over to -scsi since the proposal is to change cd0. Let's see if there are any opinions on freebsd-standards. The question is, what sort of error should we return from a peripheral driver (cd(4), da(4), etc.) open() routine when there is no media in the drive? Currently all CAM drivers will return ENXIO, and although the PR says that the acd(4) driver returns EIO, I can't tell from acdopen that it returns any errors at all if media isn't present. My guess is that EIO is getting returned sometime later in the acd(4) driver. (If that is still the case, this PR was filed in late 1999.) So is there any opinion on -standards as to what sort of error we should return on open if there is no media in a drive? Ken -- Kenneth Merry ken@kdm.org
In message: <20020822150931.A10866@panzer.kdm.org> "Kenneth D. Merry" <ken@kdm.org> writes: : The question is, what sort of error should we return from a peripheral : driver (cd(4), da(4), etc.) open() routine when there is no media in the : drive? : : Currently all CAM drivers will return ENXIO, and although the PR says that : the acd(4) driver returns EIO, I can't tell from acdopen that it returns : any errors at all if media isn't present. : : My guess is that EIO is getting returned sometime later in the acd(4) : driver. (If that is still the case, this PR was filed in late 1999.) : : So is there any opinion on -standards as to what sort of error we should : return on open if there is no media in a drive? EIO means "The device is there, but the driver had problems interacting with it" while ENXIO means "the device isn't there at all." As such, EIO is the more correct error to return in this case. I don't know if the standards speak to this specific issue (no or bad media in a device with removable media). Warner
On Thu, 22 Aug 2002, M. Warner Losh wrote: > In message: <20020822150931.A10866@panzer.kdm.org> > "Kenneth D. Merry" <ken@kdm.org> writes: > : So is there any opinion on -standards as to what sort of error we should > : return on open if there is no media in a drive? > > EIO means "The device is there, but the driver had problems > interacting with it" while ENXIO means "the device isn't there at > all." As such, EIO is the more correct error to return in this case. No, EIO means that an input/output arror occurred. open.2 only documents EIO for creating files. Otherwise open() normally doesn't do any i/o. So ENXIO is the more correct error. I think the bug is that the open doesn't succeed. The device is reported as being there at boot time, and there is enough of it there to tell which parts of it aren't there, so why not open() it so that you do things like ioctl() on it to close its door and make it there? > I don't know if the standards speak to this specific issue (no or bad > media in a device with removable media). POSIX doesn't say anything much different from open.2 about this. Bruce
On Fri, Aug 23, 2002 at 12:41:28 +1000, Bruce Evans wrote: > On Thu, 22 Aug 2002, M. Warner Losh wrote: > > > In message: <20020822150931.A10866@panzer.kdm.org> > > "Kenneth D. Merry" <ken@kdm.org> writes: > > : So is there any opinion on -standards as to what sort of error we should > > : return on open if there is no media in a drive? > > > > EIO means "The device is there, but the driver had problems > > interacting with it" while ENXIO means "the device isn't there at > > all." As such, EIO is the more correct error to return in this case. > > No, EIO means that an input/output arror occurred. open.2 only documents > EIO for creating files. Otherwise open() normally doesn't do any i/o. > So ENXIO is the more correct error. Cool. > I think the bug is that the open doesn't succeed. The device is > reported as being there at boot time, and there is enough of it there > to tell which parts of it aren't there, so why not open() it so that > you do things like ioctl() on it to close its door and make it there? There is no ioctl in the interface for loading a CD. None of the other ioctls, I think, make much sense without media in the drive. The reason we need to do a read capacity in the open() routine, which is why the open fails when there is no media, is so we can fill in the d_secsize and d_secperunit fields in the disklabel. > > I don't know if the standards speak to this specific issue (no or bad > > media in a device with removable media). > > POSIX doesn't say anything much different from open.2 about this. > > Bruce Ken -- Kenneth Merry ken@kdm.org
Responsible Changed From-To: freebsd-scsi->scsi Use short names for mailing list to make searches using the web query form work with the shown responsible. This also makes open PR show up in the summery mail.
On Thu, 22 Aug 2002, Kenneth D. Merry wrote: > On Fri, Aug 23, 2002 at 12:41:28 +1000, Bruce Evans wrote: > > I think the bug is that the open doesn't succeed. The device is > > reported as being there at boot time, and there is enough of it there > > to tell which parts of it aren't there, so why not open() it so that > > you do things like ioctl() on it to close its door and make it there? > > There is no ioctl in the interface for loading a CD. None of the other > ioctls, I think, make much sense without media in the drive. There is a CDIOCCLOSE which seems to be supported by acd and by some unmaintained cdrom drivers by not by the scsi cdrom driver. > The reason we need to do a read capacity in the open() routine, which is > why the open fails when there is no media, is so we can fill in the > d_secsize and d_secperunit fields in the disklabel. acdopen() calls acd_read_toc() which does similar things. When there is no media, acd_read_toc() fails with the not quite right error EBUSY, but acdopen() ignores this error and the open succeeds and you can try CDIOCCLOSE() to attempt to load media. So it seems that acdopen() already works like I want, and the EIO error reported earlier doesn't actually occur for acdopen(). dsopen() has similar issues. It attempts to read MBRs and disk labels and can probably return EIO for read errors when there is no media or bad media. One reason why the fd driver doesn't use the slice layer is that I never got this working well enough for floppies. It is hard to issue formatting ioctls when the open fails because the MBR is unreadable. Bruce
State Changed From-To: feedback->closed Bruce said that ENXIO was the correct error to return, and we do return that when media isn't present. Also, I believe that the issues that Bruce brought up about the CDIOCCLOSE ioctl, etc., have been fixed.
Responsible Changed From-To: scsi->ken Bruce said that ENXIO was the correct error to return, and we do return that when media isn't present. Also, I believe that the issues that Bruce brought up about the CDIOCCLOSE ioctl, etc., have been fixed.