Re: [Halevt-dev] udisks interface

[Raphaël]

On Sun, Apr 11, 2010 at 07:33:05PM +0200, Patrice Dumas wrote:
> On Sun, Apr 11, 2010 at 12:20:18AM +0200, Raphaël wrote:
> > + a libudisks directory containing most of the
> > vanilla udisks "tools/udisks.c" declarations in order to use the
> > DeviceProperties struct, collect_props(), device_properties_free()
> > and device_properties_get() (which should IMHO be part of a kind of
> > libudisks).
> > 
> > With that stuff I wish I can make an equivalent to the LibHalContext*
> > then, in the long run, make libhal itself optionnal.
> 
> Is the code available somewhere? When you are ready, I'd be interested
> by more description of where you want to have the abstraction, and
> what it changes to the current code. I think that designing carefully
> before the implementation is important, though I can also read the 
> code.
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.


libhal_ctx_set_device_property_modified is replaced by a device_changed.
That means that:
gboolean prop_equal(DeviceProperties *a, DeviceProperties *b);
needs to be done.
Empty property for invalid properties (eg, uuid for storage or vendor
for volume) may be a problem.

But there is nothing like :
libhal_ctx_set_device_new_capability,
libhal_ctx_set_device_lost_capability.

And I don't know yet about libhal_ctx_set_device_condition

> 
> > I didn't find any email about this subject on the list and find the
> > DeviceKit branche not really up to date. I would like to have your
> > thoughts about this subject, and the confirmation about the way to go.
> > Does upower a candidate for a similar interface or does these interfaces are
> > temporary solutions for a more global DBus Device Object ?
> 
> Sadly, I am not in a position to give confirmation on this. I am
> a mere follower of what other people decide (Kay Sievers, 
> David Zeuthen...). Since in the past, including a recent past, there 
> were quite a lot of changes, I am very prudent. I'd like to support 
> myself only something that doesn't move too much. However I will gladly
> accept patches -- though I could be picky since I want the
> code to remain as small and simple as possible. An abstraction of 
> LibHalContext may be the way to go, though, I don't know, and I
> am ready to hear a proposal or see code.
udisks and upower both have a Device dbus object.
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, 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 }"

> 
> I am clearly not opposed to an abstraction of some sort of the
> underlying access to the device description and event reception,
> but only if it is associated with a design of what will be done
> with that abstraction in the udisk/upower case. Or if it leads to 
> a clearer and more compact code.
> 
> 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;

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

But I need to think more before getting the beginning of an answer to
these questions.
> 
> Though the design of halevt is heavily based on ivman, no code was 
> borrowed, because there is a possibility that some code was relicenced
> from a Qt license to GPL without the consent of the author...
> 
> In the README, there is:
> 
>  The design is largely based on Ivman which was written by 
>  Ikke <eikke at users dot sourceforge dot org>, and
>  maintained by Rohan McGovern afterwards.
> 
Damned ! I missed my grep :| (probably was in src/)

Thanks a lot for your answers.

Raphaël