| Message ID | 20230315120852.19314-1-michal.michalik@intel.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net,v2] tools: ynl: Add missing types to encode/decode | expand |
On Wed, 15 Mar 2023 13:08:52 +0100 Michal Michalik wrote: > While testing the tool I noticed we miss the u16 type on payload create. > On the code inspection it turned out we miss also u8 and u64 - add them. > > We also miss the decoding of u16 despite the fact `NlAttr` class > supports it - add it. Do we have any spec upstream which needs these? The patch looks good, but I think net-next is good enough? > Fixes: e4b48ed460d3 ("tools: ynl: add a completely generic client") > Signed-off-by: Michal Michalik <michal.michalik@intel.com> > > --- Please make sure there's no empty lines between the tags and the --- separator, it confuses the scripts.
From: Jakub Kicinski <kuba@kernel.org> Sent: Thursday, March 16, 2023 5:44 AM > > On Wed, 15 Mar 2023 13:08:52 +0100 Michal Michalik wrote: >> While testing the tool I noticed we miss the u16 type on payload create. >> On the code inspection it turned out we miss also u8 and u64 - add them. >> >> We also miss the decoding of u16 despite the fact `NlAttr` class >> supports it - add it. > > Do we have any spec upstream which needs these? > The patch looks good, but I think net-next is good enough? > Yes, I faced this issue while testing the tool for the DPLL interface upstream efforts: (needed only u16, but fixed all missing) https://lore.kernel.org/netdev/20230312022807.278528-4-vadfed@meta.com/T/ I agree - net-next should be sufficient, I will change the tree and resend it. >> Fixes: e4b48ed460d3 ("tools: ynl: add a completely generic client") >> Signed-off-by: Michal Michalik <michal.michalik@intel.com> >> >> --- > > Please make sure there's no empty lines between the tags and the --- > separator, it confuses the scripts. > Ohh - please excuse me, I was not aware of that. I will keep that in mind.
diff --git a/tools/net/ynl/lib/ynl.py b/tools/net/ynl/lib/ynl.py index 90764a8..788f130 100644 --- a/tools/net/ynl/lib/ynl.py +++ b/tools/net/ynl/lib/ynl.py @@ -334,8 +334,14 @@ class YnlFamily(SpecFamily): attr_payload += self._add_attr(attr['nested-attributes'], subname, subvalue) elif attr["type"] == 'flag': attr_payload = b'' + elif attr["type"] == 'u8': + attr_payload = struct.pack("B", int(value)) + elif attr["type"] == 'u16': + attr_payload = struct.pack("H", int(value)) elif attr["type"] == 'u32': attr_payload = struct.pack("I", int(value)) + elif attr["type"] == 'u64': + attr_payload = struct.pack("Q", int(value)) elif attr["type"] == 'string': attr_payload = str(value).encode('ascii') + b'\x00' elif attr["type"] == 'binary': @@ -371,6 +377,8 @@ class YnlFamily(SpecFamily): decoded = subdict elif attr_spec['type'] == 'u8': decoded = attr.as_u8() + elif attr_spec['type'] == 'u16': + decoded = attr.as_u16() elif attr_spec['type'] == 'u32': decoded = attr.as_u32() elif attr_spec['type'] == 'u64':
While testing the tool I noticed we miss the u16 type on payload create. On the code inspection it turned out we miss also u8 and u64 - add them. We also miss the decoding of u16 despite the fact `NlAttr` class supports it - add it. Fixes: e4b48ed460d3 ("tools: ynl: add a completely generic client") Signed-off-by: Michal Michalik <michal.michalik@intel.com> --- v2: add a `Fixes:` tag to the commit message --- tools/net/ynl/lib/ynl.py | 8 ++++++++ 1 file changed, 8 insertions(+)