linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).