Re: [Halevt-dev] udisks interface

[Patrice Dumas]

On Mon, Apr 12, 2010 at 01:04:46AM +0200, Raphaël wrote:
> mine is far from ready, and probably not even enough well-designed.
> udisks part which should be included is mostly of the following :
> http://cgit.freedesktop.org/udisks/tree/tools/udisks.c
> It contains useful equivalents of hal_interface.h +
> libhal_get_all_devices, libhal_ctx_set_device_added,
> libhal_ctx_set_device_removed.

But udisk is not a library. Do you mean that you want to recreate 
a hal abstraction around udisk? It seems to me to go against what the
other people are doing...

> udisks and upower both have a Device dbus object.

For now. But it is not clear that this will stay. If you dig
in the devkit-devel archives, I remember vaguely a mail from David
saying that the DBUS stuff should not be used, but instead gnome or
gtk api should be used.

> I found this thread quite interesting about this subject.
> http://lists.freedesktop.org/archives/devkit-devel/2009-April/000147.html
> If udisks + upower is still a subset of hal, 

I haven't understood the same than you. If you read:
http://lists.freedesktop.org/archives/devkit-devel/2009-April/000140.html
udisks + upower is not a subset of hal.

> then libudev should be
> used to list devices. But a selection of the interface to use still
> would have to be done "if subsystem==block; { use udisks methods }"

That's indeed how I read how things could be. But then I am not sure
that the halevt design is right. If the new halevt is a simple layer around
libudev, it should be simplified a lot. If the new halevt has to know
which library should be used for which subsystem to retrieve the 
informations, this is also, in my opinion, a widely different software. 
More like a rewrite of hal to agregate all the different interfaces, and 
something frowned upon by the people who rewrote the stack.

> > What would be the changes besides the changes in interfacing with 
> > device property information source? How would the configuration change? 
> > Are there some similarities in udisk with hal, that is properties,
> > UDI?
> Fpr the device property, I may start with :
> typedef struct halevt_device
> {
>    char *udi;
>    struct DeviceProperties *properties; /* from udisks */
>    struct halevt_device *next;
> } halevt_device;

You cannot use directly the properties from udisk: halevt cannot be 
tied to how udisk describes a device, since halevt encompasses all the 
devices. Now if the 
  struct DeviceProperties *properties;
is generic enough and there is, at some point, a translation from udisk
properties to halevt properties, it fits in.

> Hal "udi" :
> /org/freedesktop/Hal/devices/volume_uuid_{prop-name_prop-value}
> Propery tries to be uniq, uuid for a volume, serial for storage, size
> when none are defined.
> Udisks "object path" : /org/freedesktop/UDisks/devices/sda

Does it allow for indirect reference to other devices UDI, like hal did?

> But I need to think more before getting the beginning of an answer to
> these questions.

Ok.



Right now, I am not very convinced by halevt in the new udev world. Indeed
I see 3 possibilities:

1 halevt becomes a simple listener of udev events and launches scripts
  based on udev events. In that case, I think that a rewrite should be 
  in order since it would be much simpler
2 halevt connects to specialized libraries, like udisk/upower and translates
  events and properties of these specialized libraries into more generic 
  stuff, and process udev events and properties when there is no specialized
  library (like for sound, input handling, network stuff).
  This amounts more or less to a rewrite of something with hal functionalities
  but with a different design. I don't like very much this, and it is not in
  line with the new stack, where specialized listeners are the way to go.
3 completly abandon halevt, and, instead, write little specialized 
  applications in pair, a daemon that listen to libudev and the other that 
  does something when caled by the daemon (could be a call to udisk, for 
  example).

I think the 3 is the way to go. I didn't liked the design with udev + a 
monolithic hal, then specialized daemons doing event handling and last 
actions. I prefer the current design, udev + specialized listeners and 
applications doing action handling (could be udeisk, for example, for 
block devices). This is much cleaner and simpler, in my opinion.
It is indeed simpler to write little specialized applications rather than
do-everything big applications hard to maintain. More like the old style 
UNIX way, that I like a lot ;-).

--
Pat