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 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, we won't be able
to include the magicdev changes. The patch was also discussed on the GNOME
Focus should go on gnome-volume-manager, udev and HAL now.