Re: [Halevt-dev] udisks interface

[Raphaël]

On Tue, Apr 13, 2010 at 02:11:08PM +0200, Patrice Dumas wrote:
> 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...
In
http://cgit.freedesktop.org/udisks/tree/tools/udisks.c,
at the line 277, the struct, but also collect_props() needs to be defined
for almost any application which want to subscribe to udisks.
I impulsively thought that a udisks.h header was missing in the
distribution :)
In our case, we need this struct because signals we register to return
an Object (a Device) or an array of Devices

But in fact, we have :
/usr/share/dbus-1/interfaces/org.freedesktop.UDisks.xml
and according to the udisks.c code :
"dbus-bindings-tool and dbus-glib should be able to do this for us."

So I guess that's the case for any subscriber : at compile time it
should generate its code from the XML.
And that method would be generic to any libudev->dbus daemon
(http://cgit.freedesktop.org/upower/tree/src/up-device.c)
(but I only know about 2 of them now: udisks and upower)

But the function which comparate
a set property/signal with a set match/(property-action)
is probably too specific to be autobuilt from XML.

[POF: python substitute of dbus-bindings-tool is attached]

> 
> > 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 should probably agree that no Device abstraction has to be done, from
what I saw dbus may provide a "Navigator" "page loaded" signal for
futur times, when desktop applications will want to communicate more.
I now realize it is not a good idea to try to anticipate too much about the
next device dbus-provider daemon. I should think 'device' events only.
But about gnome or gtk : here is the main reason of halevt, independance
from {K,E,Gnome} stack. I read about Xfce dev's pain to implement it and
almost forced to pull new G-dependencies."
> 
> > 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.
I understand that not ALL of Hal is in udisks + upower.
A recent thread in the udev mailing-list : 'where to grab this CPU value
without HAL ? its not in upower', answer : 'use /proc and /sys'
> 
> > 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
a kind of per-user udev daemon, but storing the property would be
painful. No XML and a very few "meaning" in the information provided.
The corresponding sub-system daemon should be requested as soon as
possible.
If none are available, libudev should at least be used to handle device
add/removal without much complexity :
'Match' against 'subsystem' and 'devpath'
'Property/Action' against libudev 'removed','added'

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

> 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 ;-).
> 
I think that the hardest thing is the XML schema of the configuration.
I'm not sure how possible it could be built from the DBus Object XML
Schema.
I think the attachement is a first step, trying to minimize the amount
of C code to type : an attempt to substitute to the handy deprecated HAL
handlers, but that's still not enough.

Raph

udisks-gen.py
Description: Text Data