FreeBSD 6.2-RELEASE-p6 amd64
This is what "cdcontrol eject" performs (incidentally, on a mounted
acd
device):
11991 cdcontrol CALL open(0x7fffffffe130,0,0x9)
11991 cdcontrol NAMI "/dev/acd0"
11991 cdcontrol RET open 3
11991 cdcontrol CALL ioctl(0x3,CDIOCALLOW,0)
11991 cdcontrol RET ioctl 0
11991 cdcontrol CALL ioctl(0x3,CDIOCEJECT,0)
11991 cdcontrol RET ioctl -1 errno 16 Device busy
11991 cdcontrol CALL exit(0xffffffff)
This is how handling of the above ioctls looks in atapi-cd.c:
...
case CDIOCALLOW:
error = acd_prevent_allow(dev, 0);
cdp->flags &= ~F_LOCKED;
break;
...
case CDIOCEJECT:
if (pp->acr != 1) {
error = EBUSY;
break;
}
error = acd_tray(dev, 0);
break;
...
In other words:
CDIOCALLOW - unconditionally send "allow" to the device
CDIOCEJECT - if device is opened by anybody else other than ioctl issuer
then return EBUSY, otherwise send "stop (without eject)",
"allow", "eject".
So, if you issue cdcontrol eject on a mounted (or otherwise opened
device) the net result is weird: CD tray is not ejected but it is
unlocked, i.e pressing a button on the physical device will eject the tray.
I think this is messy. The most obvious target is cdcontrol - it doesn't
have to issue CDIOCALLOW and actually this ioctl creates all the mess
(but read about SCSI devices below).
Possible secondary target: maybe CDIOCALLOW should also do some checking
of current access to the device.
BTW, it would be also nice to have separate 'allow' and
'prevent'
commands of cdcontrol, if just for the sake of testing.
>From a cursory glance at scsi_cd.c it seems that for SCSI CD-ROMs there
are no "in-use" checks for either of the ioctls:
CDIOCALLOW - unconditionally send "allow" to the device
CDIOCEJECT - unconditionally send "eject"
I am not sure if I like this but at least this is consistent: if I'd
issue "cdcontrol eject" on a cd device, then it would be actually
ejected no matter what. (And this is exactly because of the explicit
CDIOCALLOW from cdcontrol, because "prevent" was internally issued to
a
drive on device open). For acd it neither ejects nor preserves original
state.
So another target is inconsistency in ioctl handling between cd and acd.
And I don't want yet to cloud the matters with interaction between
scsi-cd driver and atapi-cd driver when atapicam is enabled :-)
P.S. a PR with a terse description is already opened for the above
behavior of acd:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/118779
--
Andriy Gapon