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>