Is udisks worse that HAL?

[Maxim Levitsky]

On Fri, 2010-06-25 at 13:38 +0200, Martin Pitt wrote:
> 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.

I think that udisk shouldn't know if device is usb, firewire,floppy,
cd-writer, etc...

It should use generic properties from udev rules and act upon them.
Therefore *if* floppy is so special, we could define a set of generic
properties of it and make udisk act upon them.

Or if usb,flash cards, firewire disks are very often removeable, there
should be an udev variable, and udisk should act upon it.


In other words udisk should act upon abstracted properties, and its fine
to hardcore its behaviour for that.


> 
> > 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.
I completely agree with you.

But the problem is that udisk guesses what device is and what device
isn't system internal. Thats the problem.





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


> 
> > 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.
why?

in my opinion udev is a logical extension of the kernel.
It fills the missing gaps that kernel don't because of several reasons.

So for example it is udev job solely to tell everyone if device is
removable or not.
And udisks/gvfs shouldn't look at connection type to guess that.
 



> 
> > 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"?

I mean nice descriptions gnome-disk-utility has for several types of
devices. It just has a hardcoded table.


> 
> As you say, icons are determined by udev rules, so that is "done".
Yes, but most of the time default hardcoded values are used.


> 
> 
> > (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?
It seems yes. A bit obscure to define an udev rule for a partition to be
hidden, but probably will work. I try that next time I partition the
harddisk.


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

Me happy too to help with that.


Best regards,
	Maxim Levitsky