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>. -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
