Is udisks worse that HAL?

[Baybal Ni]

Let me support Maxim. First of all, such thing as a hardware
configuration is highly non uniform. We have real scsi hdd and
cd-roms-rams and other exotic scsi machinery, pci ssd, SX8 and similar
desktop sata controllers that doesn't export normal block sata
devices, real memory cards controllers and so on. And we also have
weird power management in some disks. You simply can't hard-code them
all. Doing this, I think we will just come to the point, from where we
were coming from, this way. It doesn't matter whether we would be
having broken fdi hardcoding thing, or just simple hardcoding.

On 25 June 2010 13:53, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> 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)
> _______________________________________________
> devkit-devel mailing list
> devkit-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/devkit-devel
>