Re: [Halevt-dev] udisks interface

[Patrice Dumas]

On Sun, Apr 11, 2010 at 12:20:18AM +0200, Raphaël wrote:
> Hi,
> I recently understood that halevt was the better project to
> get automounting _the_udisk_way_ done (confirmed by the existence of a
> halevt DeviceKit branche).

I don't really have an opinion on that. It is still unclear to me what
is the final design of the udev/udisk/upower... stack. Daniel Mierswa, 
however was interested in doing such a thing, and he did the DeviceKit 
branch. However, I don't know if he did much on the branch afterwards.

> So I just begun, creating a devices_list_udisks.{h,c} and
> udisks_interface.{h,c} 

Beware that, for now, halevt is not explicitly organized for such
an abstraction. So the files and the functions may be badly organized
in that regard. Some name could hint that there is an abstraction while
it is in fact not the case.

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

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

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?

> I don't know Hal a lot, but I found that the LibHalContext* is quite a
> useful feature, abstracting disks, lids, ... and probably so much more;
> but I can't figure what will happen to that struct in the "HalSectomy" 
> process.

Nor do I. And I believe this is not really the right place to ask about 
this, since we do not decide about it, and, as far as I can tell, people 
really deciding don't read this mailing list. I believe that a better 
place would be
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
(I am subscribed too).

> Curious to heard about that. Anyway thank you for your work.
> (as a side note I just regreted that $(grep -irc 'ivman' halevt/) = 0, but I
> probably don't do enough history :))

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.

--
Pat