[PATCH] [DBus] Add support for vendor specific methods on dbus

[Avichal Agarwal]

Representation of data in hex-form is quite more understandable because there can be multiple vendor elements.
If array of bytes  is used then binary data will be sent , I agree it will remove hex to binary conversion code.
But in case of VendorElemGet , output will come as binary data .

If you want we will modify that.

Avichal Agarwal 

------- Original Message -------
Sender : Jouni Malinen<j at w1.fi>
Date : Nov 01, 2015 01:03 (GMT+05:30)
Title : Re: [PATCH] [DBus] Add support for vendor specific methods on dbus

On Thu, Oct 29, 2015 at 06:12:52AM +0000, Avichal Agarwal wrote:
> this also includes dbus.doxygen

Thanks.

> Methods are
> 1.VendorElemAdd type "is" i=integer  s=string
> 2.VendorElemGet "i" i=integer  (output string)
> 3.VendorElemRem "is" i=integer s=string

> +   
s : ielems

> +   
Hexdump of Information Element(s).


This string part is making my question whether this is really the best
design for the D-Bus interface. I had not full realized this, but with
the documentation added, it became clear that this would be a hexdump of
the binary IEs. While that is needed for the ASCII text-based control
interface, the D-Bus interface does not have such constraints and we
use ay (array of bytes) type with number of other binary items.
Shouldn't these VendorElem* methods do the same instead of require the
application using them to convert between binary and ASCII hexdump?

The attach patch is a bit cleaned up version that I was considering to
write a hwsim test case for. Please use that for any updated version if
you agree with the s (hexdump) --> ay format change.

-- 
Jouni Malinen                                            PGP id EFC895FA