Re: [Utopia] [patch] mount/unmount when starting/stopping

[David Zeuthen <david fubar dk>]

On Tue, 2004-08-17 at 13:27 -0400, Sean Middleditch wrote:
> > The rationale for removing this was to reduce the number of codepaths
> > and use as little of the features of the hardware/driver as possible. If
> > you remember a few years back there was a bug in an automounter
> > (supermount IIRC) that broke the firmware of LG drives because some
> > wellknown MMC command was selected by the vendor of the drive to mean
> > 'upload firmware'.
> 
> OK.  So assuming my hardware wasn't designed by idiots, and I'd really
> like to be able to just hit Eject and have everything work, is it
> currently possible without heavily patching HAL, GVM, etc?
> 

'echo 0 > /proc/sys/dev/cdrom/lock' would do the trick. If the disc is
mounted and forcibly removed, then the hal daemon will issue an 'umount
-l /dev/cdrom' (lazy unmount) and stuff works. Of course this may crash
badly written apps (fd's from files on the mount point will be invalid)
but anyone can write a broken app.

The implications on the kernel side for doing this, I dunno, you may
want to ask Robert or your local kernel guru.

However, it works very nicely for me.

> Besides, given the device info files, couldn't HAL just support the
> Eject event, but have it turned off by default, and then let known
> devices that support it enable it?
> 

This could be done, yes.

> Is there a utility anywhere to test if a drive supports sending the
> event?
> 

No idea, sorry.

> > 
> > Apple drives, I dunno, but I note that the eject button on my Powerbook
> > is actually part of the keyboard. That's pretty clever.
> 
> So how would that work in the current framework, then?  Would the keymap
> just call 'eject' ?  Are all the appropriate apps (Nautilus, GVM, etc.)
> ready for this, or are they expecting HAL to handle it?
> 

Presumably g-v-m or acme could do this. An interesting question is what
happens if you have several drives.

Cheers,
David