[PATCH] [DBus] Add support for vendor specific methods on dbus
avichal.a at samsung.com
Mon Nov 2 20:50:58 PST 2015
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.
------- 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
> 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
More information about the Hostap