Is udisks worse that HAL?

[Martin Pitt]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/devkit-devel/attachments/20100625/82cb7023/attachment.pgp>