Re: [PATCH net-next 10/11] tools: ynl: decode hex input

Asbjørn Sloth Tønnesen <[email protected]>
Newsgroups com.zx2c4.lists.wireguard,org.kernel.vger.linux-kernel,org.kernel.vger.netdev
Message-ID <[email protected]>
On 9/6/25 12:27 AM, Jacob Keller wrote:
> On 9/5/2025 3:51 AM, Donald Hunter wrote:
>> Asbjørn Sloth Tønnesen <[email protected]> writes:
>>
>>> This patch add support for decoding hex input, so
>>> that binary attributes can be read through --json.
>>>
>>> Example (using future wireguard.yaml):
>>>   $ sudo ./tools/net/ynl/pyynl/cli.py --family wireguard \
>>>     --do set-device --json '{"ifindex":3,
>>>       "private-key":"2a ae 6c 35 c9 4f cf <... to 32 bytes>"}'
>>>
>>> Signed-off-by: Asbjørn Sloth Tønnesen <[email protected]>
>>
>> Reviewed-by: Donald Hunter <[email protected]>
>>
>> FWIW, the hex can include spaces or not when using bytes.fromhex(). When
>> formatting hex for output, I chose to include spaces, but I don't really
>> know if that was a good choice or not.
> 
> I also prefer the spaces for readability.
I formatted it with spaces for clarity, even without spaces it was a bit
long for one line. Spaces also has the advantage that you don't have to
think about endianness.

Should we define the display hints a bit more in a .rst, or is it OK that
they end up being implementation specific for each language library? Do we
want them to behave the same in a Rust YNL library, as they do in Python?

BTW: The rest of the key used in the example can be found with this key-gen:
$ printf "hello world" | sha1sum
[redacted key material]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.