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@xxxxx> 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
