Re: Make an un-device?

[David Zeuthen <david@fubar.dk>]

On Wed, 2010-03-24 at 13:52 -0400, Paul Fox wrote:
> given how often this comes up, i think it would be very useful
> for there to be a page fully describing the reasons that the udev
> project thinks the feature is a bad idea.  when i asked in
> november for the reasons behind not being able to hide devices, i
> got somewhat vague reasons.  (and i'm clearly still not
> convinced. :-)  simply stating "suppressing events at the udev
> level is wrong" isn't terribly compelling.

I'm sorry that you don't find this compelling but it came directly from
both myself and the udev maintainer (Kay Sievers) - you are free to
check the archives for better explanations. Or if you examine, in
detail, how uevents and libudev work, you will eventually understand why
ignore_device was a terrible idea to begin with [1].

> in addition, the wouldn't the solution then apply to "all" desktops,
> instead of "GNOME and some other" desktops?

FYI, the desktops that are covered by e.g. UDISKS_PRESENTATION_HIDE
includes desktops for which the following statements are true

 - they are using GVolumeMonitor to draw icons

 - they are shipping gvfs with the udisks (or DeviceKit-disks) volume
   monitor backend

which includes GNOME and, I think, XFCE, on most modern distros.

IMNSHO, it is rather naive to demand that "all" desktops need to
implement some feature (such as configuring what drives to ignore). It's
not like desktops share a lot of code or specs.

Good luck,
David

[1] : Hint: ignore_device only suppressed invocation of rules - the
uevent was still emitted and the device would still be part of any
enumeration either via libudev or sysfs.

<ramble>
What most people don't understand is that udev is just one tiny piece in
the *middle* of the stack... a stack where elements in the stack are
free to bypass layers - e.g. it is perfectly fine for a desktop app to
look in sysfs, thereby bypassing, say, udev and udisks.
 
So even if we still had ignore_device and things on top (like udisks ->
gvfs -> nautilus) actually respected it, it wouldn't work for the app
looking directly in sysfs (or /proc/scsi/scsi or whatever).
</ramble>.