Is udisks worse that HAL?

[Martin Pitt]

Hello Maxim,

Maxim Levitsky [2010-06-25 16:18 +0300]:
> 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.

I have a feeling that this wouldn't actually make things any easier,
since with this you'd have to express everything about detection and
policy decisions in terms of udev rules. For the particular example of
floppies, we'd have to replace a piece of code like

|      if (!g_udev_device_get_property_as_boolean (device->priv->d, "ID_CDROM") &&
|          !g_udev_device_get_property_as_boolean (device->priv->d, "ID_DRIVE_FLOPPY"))

with something like

| ENV{ID_CDROM}==1, ENV{UDISKS_DONT_PROBE}=1
| ENV{ID_DRIVE_FLOPPY}==1, ENV{UDISKS_DONT_PROBE}=1
[...]
|      if (!g_udev_device_get_property_as_boolean (device->priv->d, "UDISKS_DONT_PROBE")

How would this be easier or more efficient or easier to maintain? It
would just further clutter the rules, slower probing, etc, but what's
worse, clutter the udev database with all sorts of intermediate
internal state variables. And I'm afraid there's going to be a lot of
them.

Now, this might be the right thing in some cases, like
UDISKS_PRESENTATION_NOPOLICY, where it does make sense for third
parties to change the rules, but it wouldn't make sense for the
"broken media probe" case IMHO. We know that we mustn't probe floppies
for media, period.

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

You mean "hotpluggable". For this particular case I tend to agree.
It's an interesting hardware property which wouldn't hurt to be an
udev property. I don't consider it "configuration", but then again
most udev properties aren't. 

However, if you look into the actual code of
update_info_is_system_internal(), it becomes clear that udev rules are
simply not expressive enough to figure this out. You'd need some
external helpers again, and at that point it would become even more
complicated than it is right now.

So if it helps for things further up the stack, it can easily be
arranged to export the "is system internal" flag as an udev property.

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

That's not going to go away, though. Whether we "guess"
hotpluggability in terms of udev rules or in terms of C code doesn't
change the fact that at some point something has to decide what the
notion of "system internal" is supposed to mean. What it does change
is that it would be more explicit for people looking directly at the
udev DB instead of reading the udisks D-Bus object properties.

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

I disagree. udev itself (as in the daemon) should know nothing about
hardware whatsoever, but concentrate on what it's supposed to do:
provide a property database and multiplex/announce kernel events to
userspace. The probers should know about particular types of hardware,
of course, and some are shipped with udev (as in the package), and
lots of other more specialized things like util-linux (blkid) or
udisks.

So it could be argued that blkid should take over the job of
determining whether or not a device is hotpluggable or not, but it
would be all the same code just put into a different place. Why is
udisks any worse a place than e. g. the blkid prober? Also, didn't you
just argue above that you want explicit udev rules to determine
hotpluggability? So those would end up in udisks' rules again after
all.

So how do you think a good solution for this would look like?

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

I still don't understand, I'm afraid. So gdu has a table which assigns
the string "80 GB Festplatte" (e. g. in German) to my /dev/sda. Where
else than gdu should this live? NB that we want to keep out user
visible strings from system daemons, since i18n is very awkward to
handle at this level, and system daemons shouldn't care about
providing user-visible strings in the first place (except data read
from the devices themselves, of course, like disk labels).

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

Right, but that's just because nobody has sent any more special ones.
We can easily (and did) integrate them into the rules. That said, I'm
still unsure which level of the stack should decide about things like
icons. I think gdu would be a more appropriate place for this than
udisks rules. This is still a bit underdesigned.

Thanks, and have a good weekend,

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)