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? 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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
