DBUS API questions

[Michael E Brown]

On Tue, May 01, 2007 at 11:36:37PM -0400, David Zeuthen wrote:
> 

David,
    Thanks for the very detailed response. I have several concerns,
questions, clarifications, etc.

1) I have layers of stuff that I would like to export.

    Lowlevel:
    a) raw smbios table
    b) individual raw structures in the table
    c) ability to access specific offsets in specific structures

    Midlevel:
    a) ability to access parsed dell-specific structures.
    b) token control - activate token, get/set token strings.
    c) raw SMI functions
    d) parsing raw smbios info into human-readable form

    Highlevel:
    a) bios update
    b) radio control
    c) LED control
    d) LCD brightness
    e)  ... other stuff ...

Basically, I think that it would be good that the lowlevel/midlevel
stuff goes into a dbus daemon and the highlevel stuff goes into hal,

> So that's pretty much it; the spec discusses how to throw exceptions
> from your program. The only caveat is that method calls implemented this
> way always return an integer; that's something we're going to fix for
> HAL 0.5.10 (in a way so compat is preserved) so all types used by HAL
> (which is int, uint64, string, strlist, bool, double) can be returned.

This ends up being a problem. Most of the lowlevel and some of the
midlevel functions need to be able to return something more than an int.

The other thing that I was looking at is a way to get away from HAL
calling libsmbios command-line utilities, and getting a more clean way
for HAL to call into libsmbios functions. I was thinking a dbus
interface for my stuff would make sense for this. Does HAL have an easy
way to interface to access stuff that already exists on dbus?

> 
> All these code paths are pretty stable since they are being used quite a
> few places in HAL.. these feature also been available since.. I think
> HAL 0.5.6 (or earlier) so it's supported by all the distros from last
> year I think (I also think it's safe to assume that 95% or higher of all
> Linux installations has HAL available).
> 
> Of course.. everything depends on what interface you want to export via
> the IPC interface. I'm a big fan of exporting only high-level interfaces
> that lets people do what they want in a single method call which I think
> is what you're trying to say below with e.g. UpdateBIOS(). Exporting all
> sorts of implementation details makes it a lot harder...

There are two sides to this. With one SMI calling interface function, I
can implement probably about a hundred higher-level functions. I'm not
sure I have enough manpower (just me) to implement all of these.

> I'm also not sure it's worthwhile sending out signals for RadioChanged()
> etc. - this is so standard behavior that eventually HAL should send out
> D-Bus signals like these thus rendering the signals provided by a
> hypothetical org.libsmbios service less than useful.

But this means that *everything* would have to go through HAL.

I'm was thinking of trying to make a little something that can satisfy
everybodies needs without conflicting. Currently HAL is just calling the
libsmbios binaries. This means that we might get confused if user goes
behind the scenes and runs the binaries to change settings themselves.

If I implement this via dbus with signals for changes, anybody who is
interested can update their internal state if somebody changes things
out of band.

> So I guess I'm saying, for the Dell specific things like UpdateBIOS()
> I'd just merge an interface onto the root device object that exports
> these. All this, as explained, can live in a libsmbios package; it's
> just installing an XML file in the appropriate place...

This sounds reasonable except for the SMI and token interfaces. I dont
see the advantage of implementing using hal vs dbus. I dont know much
about it yet, though, so I could be wrong.

> Everything else should just be implemented in a vendor-agnostic way in
> HAL just like HAL uses libsmbios for laptop backlight and RF kill
> functionality. That has the benefit that if someone writes a kernel
> driver or ports libsmbios to the kernel for some of this... we can just
> use the kernel interface instead. 

Where there exists a vendor agnostic way. I have a *ton* of stuff
related to BIOS settings that has no way to really be vendor
agnositic. Additionally, some of the BIOS settings stuff conflicts with
the stuff above (wirelessctl,ledctl, etc) such that I would like to
notify others if user changes settings another way.

Basically, I'd like a way to have a method to deliver dell-specific
stuff to my users. 

Let me put it this way: using a single function call, I can implement
almost 50-100 high-level interfaces pretty quickly. Probably 10 or less
of these will be of any interest for a vendor agnostic HAL interface.

What I am really trying to do is save myself some work. My lowlevel
stuff is all in C++. I'd like to write a python wrapper for that
lowlevel function, write highlevel interfaces in python and export those
all via dbus. This solves several problems. 1) root access problem, 2) I
get to implement in python which is much quicker.

Then, for all of the interfaces that we want to make vendor agnostic, I
can write a wrapper that does a facade pattern between the HAL interface
and my high-level interface.

> Also, it means that other vendors can add the same functionality and
> that the desktop / UI bits don't have to be specific to a given vendor
> [1]. Which is what you guys benefit from now with the patch that was
> integrated into HAL to use libsmbios for setting the backlight - e.g.
> now things Just Work(tm) with KPowerSave, gnome-power-manager and other
> applications that uses HAL (will rebuild HAL for Fedora 7 to use this
> post-merge)

Yeah, but I have lots of other things besides just the few things
already implemented in HAL. (as mentioned above)

Speaking to the kernel thing: I think I have pointed out in a few other
forums that this is the wrong way to go in my case. Most of the Dell
stuff can more easily implemented almost entirely in userspace. It
doesnt make much sense to me to push all that parsing stuff into the
kernel when I can just as easily do it in userspace.

> (In fact, much of that is happening for backlight drivers from other
> vendors since the kernel gained the backlight class.)

And I think that the other vendors can do whatever they want. I think it
is more code to crash a kernel with, though, and dont agree with adding
a Dell interface for this to the kernel when I have a perfectly
serviceable userspace solution. Just meanst that people running Dell
boxes will have one less thing to crash/bloat their kernel.

> And I'm more than happy to make HAL use libsmbios even more where it
> makes sense / help out with how to integrate libsmbios with the HAL
> extension points. I also know that Bastien is looking into the light
> sensor stuff.
> 
> Whee, that was a long mail; hopefully it made some sense. How does my
> proposal sound?

Some of it makes sense, some of it I am still pondering.

--
Michael