New standard proposal

[Derek Foreman]

On Sat, 27 Sep 2003, Carlos [ISO-8859-1] Perelló Marín wrote:

> El sáb, 27-09-2003 a las 06:58, Derek Foreman escribió:
> 
> [...]
> 
> > > > Which ioctl?  I'd like to see how my drive reacts to it.
> > > 
> > > Just look at this:
> > > 
> > > http://www.ussg.iu.edu/hypermail/linux/kernel/0202.0/att-0603/01-cd_poll.c
> > 
> > Thanks
> > 
> > Unfortunately, it doesn't work on my machine (linux kernel 2.6.0-test5).  
> 
> 
> I did only test it with Linux 2.4, of course it should work with Linux
> 2.6 and any other Unix (*BSD).

I've already been given patches to test on 2.6, and that code seems to run 
properly on my machine now.

> > AFAICT, the command was introduced in MMC2, yet two of my 4 drives don't 
> > support it at all.  (so you'll need a different detection method for a 
> > lot of drives)
> 
> 
> Does magicdev or autorun work with those drives?

autorun uses a different method entirely.  The ioctls it uses work on all
my drives.  The first match in my google search for magicdev tells me it 
uses the same ioctls autorun does.

These ioctls don't have the ability to report eject button presses on 
locked drives like the mmc "get event" command can (for a subset of drives 
that understand get event commands at all)

I think you can count on all drives supporting CDROM_DRIVE_STATUS and 
CDROM_DISK_STATUS as used in autorun and magicdev, so you can just fall 
back to that if the drive fails on get event.

I think failure should be defined as returning any error at all (one of my 
drives will return "medium not present" to this command if there's no
disc in it, in a sane world it would always return "invalid opcode".) Or, 
the command completes successfully, but returns 0x80 for the 3rd byte in 
the header (buffer[2] in that example code).  Which would mean the drive 
can return event notification, but not for "media" events.

> > The other two drives accept the command, but the command's buffer comes 
> > back still full of 0s.  This appears to be a kernel bug, since sending the 
> > same command with SG_IO behaves as expected.  I've reported this on the 
> > linux kernel mailing list.
> 
> I'm developing the poll method as Linux Kernel hackers told me that I
> should do it so I hope it will work always, just give me more time to
> improve it :-)

:)