DBUS API questions

[David Zeuthen]

On Wed, 2007-05-02 at 03:05 -0500, Michael E Brown wrote:
> > 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. 

Actually only the RF Killswitch stuff uses binaries and even that was
clearly marked, at the time of code import, with a TODO to only depend
on the libsmbios library. The backlight stuff is a separate binary (uh
written in C++) that links with the libsmbios library.

> Does HAL have an easy
> way to interface to access stuff that already exists on dbus?

Of course. But I'm reluctant to do this since it adds more complexity
wrt. error handling and so forth. There's just no point in calling into
a D-Bus service if your process is already privileged to do the work
in-process and a library is already available.

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

Why is that bad?

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

My point really was that your high-level interface for vendor-specific
stuff would _also_ go through HAL. You'd just use export an interface

 org.libsmbios.HighLevelStuff

on the root computer device object in HAL with your high-level
functions.

Another point of mine is that it's bad idea to expose low/mid-level API
since your UI apps (cmdline, ncurses, GTK+, KDE based or otherwise)
probably is only interested in the high-level interfaces; I mean, for
the app to be useful to needs to expose high-level stuff to the user; no
reasonable app is going to care about anything else I think?

So I'm saying just write your code as a HAL method call; it's not going
to be more work, in fact it's going to be _less_ work:

 - it's easier to write your high-level method if you can interface
   with the low/mid-level stuff in-process e.g. via libsmbios. So your
   code will be simpler.

 - Exposing a complex API like the low/mid-level you propose via an
   IPC mechanism is going to be hard. IPC is just hard; there's a lot
   more error checking you need to do since the remote end is a separate
   process (that may not be available; that may die; permission
   problems). There's also a significant overhead performance wise with
   a ton of round trips

 - Assuming you choose to expose low/mid-level over D-Bus it seems that
   every app will have to map that to high-level stuff to do anything
   useful _anyway_. This means code duplication in every cmdline,
   ncurses, GTK+, Qt etc. application that wants to use your code.

   Unless you write a library they all use but this brings other
   problems of forcing the app authors to choose a programming language.

 - it's not more work / harder to just implement this as HAL methods
   than writing an app that uses your low-level stuff. In fact, I
   think I've argued it's less work - instead of your app having to
   call a ton of D-Bus functions it simply calls a single high-level
   function on HAL that starts a program that does the bulk of the
   work.

So, to reiterate, I guess my advice is that you should only export
high-level functions and you should do so using HAL methods; it's just
easier.

If you do decide to export low/mid-level stuff, keep in mind that you
need to start a system-wide daemon at boot time (many distros frown at
this) - when we get system bus activation in D-Bus (still a few months
out) of course you can remove this so your code is only started on
demand.

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

Yeah, I don't disagree with you on that one. I was just pointing out the
flexibility of having abstraction in HAL etc.

Hope this helps.

     David