Binder interface for wpa_supplicant?

[Christopher Wiley]

On Wed, Jan 6, 2016 at 1:04 PM, Johannes Berg <johannes at sipsolutions.net> wrote:
> On Wed, 2016-01-06 at 09:48 -0600, Dan Williams wrote:
>>
>> Would be nice for the D-Bus side of things too, since I'm pretty sure
>> we'll never be able to convert to GDBus due to the
>> dependencies.  Also, if/when the kdbus success shows up, I'm sure
>> we'll want to support that too, and the code may or may not be
>> similar to the existing dbus code.
>>
>
> Yeah. Ideally we'd be able to generate code for the existing (and
> proposed binder) interfaces; however, I don't think that's actually
> going to be possible since each one of the existing ones has its own
> quirks already that we'd have to keep if we really were to convert.
>
> Perhaps, with dbus, it'd be possible to add "dbus-new2" that would
> follow some new tbd semantics, what would you think about that?
>
> As far as binder is concerned, at the core it's just a binary message
> passing - what kind of API do you (Christopher) envision on top? Did
> you already start working on this? What kind of marshalling does this
> use? Is it typically object-oriented, like dbus?

Binder is very much an object oriented RPC mechanism.  It exposes
primitives to obtain references to objects in remote processes, and call
methods on those objects.

The object model we have in mind is wpa_supplicant's DBus model.  In
particular, we're working on retrofitting shill (chrome os's connnectivity
manager) to use binder when running in an Android context (as part of
the Brillo project).  That daemon currently interfaces with supplicant
through DBus (the newer binding), and that will guide our immediate
implementation.

>
> It seems to me that it would be possible to define, in some object-
> oriented fashion, the API used, and then map that to the different
> interfaces (socket/ctrl-iface, dbus, binder) in some build-time step.
>
> johannes
>
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap