Unmounting and 'eject' press

[Mathieu Lacage]

On Thu, 2004-06-03 at 13:12, Ikke wrote:

> Thanks for the information. I don't think the actual problem can be solved
> by this tough :-s What we actually need is to know when we should eject the
> drive (i.e. when the user presses the button). I suppose you're familiar
> with *nix systems, so you know, when you want to use a removable volume like
> a cdrom, you need to mount it, and the tray gets locked untill the device is

I never really understood why it was so. It should be possible for a
shell or any tool which reads the mounted directory to get an error when
doing a readdir or read on the mounted non-locked ejected CD. As such,
there is no real need to lock the drive.

Of course, this will work only if the kernel and user code do proper
extensive error checking but that should already be the case for all
decent code.

> unmounted. So the user is not able to open the tray at all.
> What we need is something like this:
> - if the disc is not mounted and the user presses 'Eject', the disc is
> ejected (thats already the case today)
> - if the disc is mounted and not in use, we should in one way or another
> detect that the user pressed ejectn unmount it in software, and call the
> CDROMEJECT ioctl on the device, so the user can take out the disc
> (completely transparent: the user shouldn't know about the unmounting stuff
> and so)
> - if the disc is mounted and in use, warn the user it's in use, wait untill
> it is released by all processes, unmount and eject (or something else,
> depends on configuration/implementation). So the big issue is not to know
> wether the tray is opened or not, there are standard ioctl call for that if
> I'm not mistaken, but to know when we should call umount on the device. And
> this seems quite impossible :-s

yes.

> One possible, but bad solution:
> On disc insert, mount the disc, but unlock the tray after that. If the tray
> is opened (user pressed eject), a Hal message should be emitted (isn't it?
> should test that), or if not, poll (with your code, standard linux code,
> whatever) (which is bad behaviour, but well, no other choice). Then we could
> check wether the device was still in use by some program, if it was, warn
> the user, tell him what program was using the disc, and maybe ask him to
> re-insert it. If it wasnt in use anymore, just umount it (propably forced?
> Should test too). But this *is* bad behaviour, because processes using the
> cd when its ejected could crash or something alike...

No, it does not sound like bad behaviour. Theorically (and in practice I
think), the reading processes should get an error code from their read
commands.

This sounds like the right solution. I have never been totally thrilled
by the idea of locking a drive. The kernel and user code should already
do proper error checking of all functions dealing with the drive.
Somewhere, when an error is propagated, you should check the drive
status. This is what we did at the application level: upon any read
error on the unlocked drive, we checked the ejection status.

> David, I compiled
> http://www.ussg.iu.edu/hypermail/linux/kernel/0202.0/att-0603/01-cd_poll.c ,
> it doesnt run on my cd reader (so I guess tht one isnt mmc2 or Media Status
> blablabla compliant), and asked some other people to run it and play around
> with their reader. Most of them got messages telling a disc was inserted or
> removed, but not whe eject was pressed, so I guess a lot of cdrom players
> don't implement mmc2 completely, only some parts (i.e. not the eject part).

yes. This has been my experience. 

> 
> Still looking further, but I'm afraid I'll be forced to use "the dirty
> method", making the tray unlocking configurable, and trap the EjectPressed
> event if configured to do so, i.e. when the drive supports it (using a small
> testing app for the user to test if his drive does).

That does not seem ugly to me.

regards,
Mathieu

PS: is there a post-only thingy for fdo mailing lists ? I believe the
list admin is going to hate me when he gets to moderate my posts from
this unsubscribed address.
-- 
Mathieu Lacage <mathieu.lacage at sophia.inria.fr>


_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal