Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Dec 2007 14:59:13 +0200
From:      Andriy Gapon <avg@icyb.net.ua>
Cc:        freebsd-stable@freebsd.org, Nikos Vassiliadis <nvass@teledomenet.gr>
Subject:   mounted cd, tray locking, cdcontrol
Message-ID:  <476A6721.5020404@icyb.net.ua>
In-Reply-To: <47610957.8020800@icyb.net.ua>
References:  <475FC26C.3030508@icyb.net.ua> <200712130930.08558.nvass@teledomenet.gr> <4760FE68.60001@icyb.net.ua> <200712131213.37478.nvass@teledomenet.gr> <47610957.8020800@icyb.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?476A6721.5020404>