Re: [PATCH] block: Better CDROMEJECT

[john stultz <johnstul@us.ibm.com>]

On Tue, 2005-12-20 at 09:07 -0500, Ben Collins wrote:
> On Tue, 2005-12-20 at 14:39 +0100, Jens Axboe wrote:
> > > Should be an easy check to add. In fact, I'll resend both patches with
> > > that in place if you want.
> > 
> > There's still the quirky problem of forcing a locked tray out. In some
> > cases this is what you want, if things get stuck for some reason or
> > another. But usually the tray is locked for a good reason, because there
> > are active users of the device.
> > 
> > Say two processes has the cdrom open, one of them doing io (maybe even
> > writing!), the other could do a CDROMEJECT now and force the ejection of
> > a busy drive.
> 
> But that's possible now with "eject -s" as long as you have write access
> to it. Most users are using "eject -s" anyway.
> 
> You can't stop this from happening. However, the fact is that a lot of
> devices (iPod's being the most popular) require this to work.

I'm a little confused. Eject has a number of different ways it
interfaces with the kernel (scsi, cdrom, floppy, tape), which I assume
map to different ioctl commands. In the case I'm familiar with (my usb
ipod, and my firewire disk), the scsi method (via eject -s) is used
which sends a ALLOW_MEDIUM_REMOVAL.

Now I know without passing a specific method, eject will try different
methods until one works, but it seems that the patch below is overriding
the CDROMEJECT ioctl so that it then sends an ALLOW_MEDIUM_REMOVAL as
well as the normal GPCMD_START_STOP_UNIT.

Again, I don't know about the hardware bits, do you want
ALLOW_MEDIUM_REMOVAL to be sent to cdroms when the "eject -r" option is
used, or just for "eject -s"?

Or maybe your patch is addressing more then just my issue w/ USB and
Firewire devices and that is the disconnect on my side?

> Here's the patch. Currently it will not even try the
> ALLOW_MEDIUM_REMOVAL unless they have write access (to avoid returning
> an uneeded error for people using eject -r that isn't patched to open
> the device O_RDRW). However, I still changed the __blk_send_generic()
> function to use verify_command().

I'll play with your patch tonight and let you know how it goes.

Although from just looking at it, don't you still need to add
ALLOW_MEDIUM_REMOVAL in the verify_command() list for this to work?

Alternatively, would just the "safe_for_write(ALLOW_MEDIUM_REMOVAL);" in
verify_command along with the eject-opens-RW fix have almost the same
effect?

thanks
-john