Hello Maxim, Maxim Levitsky [2010-06-24 18:38 +0300]: > it, and libraries that support it have just too many hardcoded > assumptions. > > Why it was done this way?
To simplify and robustify the code base and avoid getting us into the same swamp than with hal fdi files, where you needed tons of them, and additional several fdi files tried to "fight" each other. > Isn't a point of rewrite to create something better? Exactly! > For example it would set 'system internal' on all devices but few > hardcoded device types. > > In my opinion _all_ configuration must not be hardcoded, and since you > choose udev, it should be stored in udev rules, where it can be edited > by the user. Just that in this particular example, the question whether or not a device is system internal is _not_ configuration, it's an immanent property of that device. That is to say, udisks certainly has bugs in that regard (for example, it is just about impossible to tell whether an esata drive is internal or external, and some better heuristics certainly wouldn't hurt), but still those are bugs, not configuration problems. > I found that gvfs-volume-monitor from gvfs, hardcodes the device > interfaces it will mount. > It only mounts > > > if (g_strcmp0 (connection_interface, "usb") == 0 || > g_strcmp0 (connection_interface, "firewire") == 0 || > g_strcmp0 (connection_interface, "sdio") == 0 || Same rationale by and large. We shouldn't automount internal drives, so this shouldn't be configurable. However, I do agree that there should be some abstraction here, gvfs looking at hardware connector types is wrong. It should just ask udisks whether the drive is removable. I think it actually did at some point, and then this was made more strict for some reason, so some git history reading is in order. > Now xD interface (which is 8 bit standard nand interface) isn't > anything of above. Right, and that it's not working is a bug. But it should be fixed, not worked around by tweaking udev rules and pretend it was configuration IMHO. > Everything, device names, descriptions, even icons by default (this > is possible to override) are hardcoded. Device names come from the kernel and should not ever be munged by udev rules in the udisks context. What do you mean in particular here? What do you mean by "descriptions"? As you say, icons are determined by udev rules, so that is "done". > (I for example had a thought to mount a seperate partition to > /home/maxim/software because I compile stuff there too often. But I > don't want it to show it on desktop. You can set up a custom udev rule to set UDISKS_PRESENTATION_NOPOLICY=1; isn't that precisely the kind of configurability you are asking for? > And even udisks udev rule hardcodes UDISKS_PRESENTATION_NOPOLICY=1 > for everything but few hardcoded devices... Right, because it has been easier to specify a positive list than a blacklist so far. If you have something particular which isn't covered here, please file a bug. I'm happy to fix it, or discuss patches with you, of course. Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
_______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
