From: Christian Schmitt <chris@ilovelinux.de>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev rule for unmount action
Date: Wed, 10 Jun 2009 19:34:09 +0000 [thread overview]
Message-ID: <200906102134.10087.chris@ilovelinux.de> (raw)
In-Reply-To: <200906061702.10974.chris@ilovelinux.de>
On Tuesday 09 June 2009 02:45:57 David Zeuthen wrote:
Hi David,
> That's a very interesting blog entry, thanks for sharing. My experience
> dealing with the storage stack in GNOME is that people keep asking for
> this feature.
... and KDE users obviously, too ;-)
> Actually I think doing this on the desktop level is the way forward.
> There are two problems here.
>
> First, consider a USB optical drive attached to the system. A typical
> thing you want to do here is to eject the disc so you can insert another
> one. Now, to eject media you first have to unmount it before you can
> send the eject ioctl to the device. But if you hook into the unmount
> process then you unbind the device before it is mounted and you never
> get to send the eject ioctl.
>
> The other example is when the user manually wants to unmount a partition
> instead of ejecting it. Now, in the Nautilus file manager we do default
> to ejecting stuff (the eject icon in the sidebar) but the user can also
> right-click and click on Unmount in the context menu. If you hook into
> the unmount process then the device(s) actually disappears, much against
> what the user wanted.
Perfectly right. And that is why it would make sense IMHO to let the user
specify special treatment for certain devices (like it is possible with udev
rules (serial number, manufactor, model....)).
Actually, I am asking myself if the eject command is sufficient in this case of
a certain external HD device that seems to need some more commands to go into
suspend mode. That's why I think it would make more sense not to hard-wire
certain detach/supend/spindown commands, but make them selectable for every
device. Well, just some brainstorming. :-)
> Anyway, it's not a problem to do all this from the desktop level and I
> just added support for this.
As you seem to be a GNOME guy, I'll probably have to wait until someone starts
to integrate DeviceKit support into Solid. Are you aware of any work in this
direction?
Thanks for your effort.
Cheers,
Chris
prev parent reply other threads:[~2009-06-10 19:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-06 15:02 udev rule for unmount action Christian Schmitt
2009-06-06 16:27 ` Marco d'Itri
2009-06-07 13:05 ` Christian Schmitt
2009-06-08 12:38 ` Karel Zak
2009-06-08 14:42 ` Christian Schmitt
2009-06-09 0:45 ` David Zeuthen
2009-06-10 19:34 ` Christian Schmitt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200906102134.10087.chris@ilovelinux.de \
--to=chris@ilovelinux.de \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).