GNOME Bugzilla – Bug 119892
Experimental patches to let magicdev control locking of CD-ROM
Last modified: 2005-08-15 01:35:39 UTC
We have users found it as a surprise when they can't eject their CDs even when they are not in use. Some even call in here for support because they think there're something wrong with the software and our answer is just to click the right mouse there. This is due to the nature of usage of Linux in Thailand, mainly to replace proprietary software. So Thai linux users are not hackers. But NECTEC would like them to use Linux (or they will get Windows installed) so we try to make the transition as painless as possible. This patch is the first of my experiment with the kernel. I first learn that it is impossible to do this (ejectable) without modifying the kernel. Supermount can do this but it modify the kernel too much. My approach is to add an API to the CDROM driver for user-space to query the mount status of its device, specificially the question "is it ok to umount?" (will umount() return EBUSY) The API is implemented as a new ioctl, add 40 lines to cdrom.c. The other part in magicdev is easy. It's just a new state BUSY and functions to handle transitions between new/old states. Magicdev also have to handle auto-umount which happend when user eject the CD, magicdev must be the one who umount the device. The result will be like this :- - user insert CD - magicdev mount - user play an mp3 file - magicdev lock - user stop using the (any) file - magicdev unlock - user eject CD - magicdev umount Please make comments about this approch. Having to modifying the kernel for this feature lead me to bug it here first, to make sure that I make the right decision before proposing to the kernel mailing list. Thanks.
Created attachment 19219 [details] [review] Add new ioctl to CDROM driver to query mount status
Created attachment 19220 [details] [review] Add new state/transition and auto-umount
Unfortunately, if you mention the word 'magicdev' on the kernel mailing list, people will likely flame you or ignore you. :-( So, you are best off proposing your change without mentioning what I thought of it. One concern about this approach is that it seems possible that the CD might become temporarily busy before the user actually started using it, and then magicdev would unmount it. Also, if a user stuck in a CD, and magicdev mounted it, the user couldn't unmount it until they actually opened the CD in the file manager. So, it seems like users might see this approach as a bit confusing and unreliable.
> One concern about this approach is that it seems possible > that the CD might become temporarily busy before the user > actually started using it, and then magicdev would unmount it. I don't understand what you mean, but concern. Can you clarify? > Also, if a user stuck in a CD, and magicdev mounted it, > the user couldn't unmount it until they actually opened > the CD in the file manager. No. They can always use the same old reliable right-click :-) The changes are only that 1) The rule for locking: change from "always lock after mount" to "after mount, lock only when anything is use, unlock otherwise". So users can eject only when CD is not in-use. 2) Who-do-the-locking: change from "the kernel" to magicdev. Other than this, nothing change. I can use "mount", "umount", "right click" "magicdev auto-mount/auto-umount" or any mean to mount/umount the volumes. Only visible change is that now I can eject CDs when it is not in use by any program (plus auto-umount).
Adding the PATCH keyword and upgrading the priority level to High due to the attached patches.
As the patches haven't been accepted in the kernel upstream[1], we won't be able to include the magicdev changes. The patch was also discussed on the GNOME mailing-lists[2]. Focus should go on gnome-volume-manager, udev and HAL now. [1]: http://www.uwsg.iu.edu/hypermail/linux/kernel/0308.3/0484.html [2]: http://mail.gnome.org/archives/desktop-devel-list/2003-August/msg00217.html