summaryrefslogtreecommitdiff
path: root/tools/net/ynl/cli.py
AgeCommit message (Collapse)AuthorFilesLines
2024-03-08tools/net/ynl: Report netlink errors without stacktraceDonald Hunter1-7/+11
ynl does not handle NlError exceptions so they get reported like program failures. Handle the NlError exceptions and report the netlink errors more cleanly. Example now: Netlink error: No such file or directory nl_len = 44 (28) nl_flags = 0x300 nl_type = 2 error: -2 extack: {'bad-attr': '.op'} Example before: Traceback (most recent call last): File "/home/donaldh/net-next/./tools/net/ynl/cli.py", line 81, in <module> main() File "/home/donaldh/net-next/./tools/net/ynl/cli.py", line 69, in main reply = ynl.dump(args.dump, attrs) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/donaldh/net-next/tools/net/ynl/lib/ynl.py", line 906, in dump return self._op(method, vals, [], dump=True) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/donaldh/net-next/tools/net/ynl/lib/ynl.py", line 872, in _op raise NlError(nl_msg) lib.ynl.NlError: Netlink error: No such file or directory nl_len = 44 (28) nl_flags = 0x300 nl_type = 2 error: -2 extack: {'bad-attr': '.op'} Signed-off-by: Donald Hunter <donald.hunter@gmail.com> Link: https://lore.kernel.org/r/20240306231046.97158-3-donald.hunter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-03-06tools: ynl: add --dbg-small-recv for easier kernel testingJakub Kicinski1-1/+6
Most "production" netlink clients use large buffers to make dump efficient, which means that handling of dump continuation in the kernel is not very well tested. Add an option for debugging / testing handling of dumps. It enables printing of extra netlink-level debug and lowers the recv() buffer size in one go. When used without any argument (--dbg-small-recv) it picks a very small default (4000), explicit size can be set, too (--dbg-small-recv 5000). Example: $ ./cli.py [...] --dbg-small-recv Recv: read 3712 bytes, 29 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 Recv: read 3968 bytes, 31 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 Recv: read 532 bytes, 5 messages nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 [...] nl_len = 128 (112) nl_flags = 0x0 nl_type = 19 nl_len = 20 (4) nl_flags = 0x2 nl_type = 3 (the [...] are edits to shorten the commit message). Note that the first message of the dump is sized conservatively by the kernel. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-01tools/net/ynl: Add --output-json arg to ynl cliDonald Hunter1-3/+19
The ynl cli currently emits python pretty printed structures which is hard to consume. Add a new --output-json argument to emit JSON. Signed-off-by: Donald Hunter <donald.hunter@gmail.com> Reviewed-by: Breno Leitao <leitao@debian.org> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240129223458.52046-2-donald.hunter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-28tools: ynl: introduce option to process unknown attributes or typesJiri Pirko1-1/+2
In case the kernel sends message back containing attribute not defined in family spec, following exception is raised to the user: $ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/devlink.yaml --do trap-get --json '{"bus-name": "netdevsim", "dev-name": "netdevsim1", "trap-name": "source_mac_is_multicast"}' Traceback (most recent call last): File "/home/jiri/work/linux/tools/net/ynl/lib/ynl.py", line 521, in _decode attr_spec = attr_space.attrs_by_val[attr.type] ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^ KeyError: 132 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/jiri/work/linux/./tools/net/ynl/cli.py", line 61, in <module> main() File "/home/jiri/work/linux/./tools/net/ynl/cli.py", line 49, in main reply = ynl.do(args.do, attrs, args.flags) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jiri/work/linux/tools/net/ynl/lib/ynl.py", line 731, in do return self._op(method, vals, flags) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jiri/work/linux/tools/net/ynl/lib/ynl.py", line 719, in _op rsp_msg = self._decode(decoded.raw_attrs, op.attr_set.name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/jiri/work/linux/tools/net/ynl/lib/ynl.py", line 525, in _decode raise Exception(f"Space '{space}' has no attribute with value '{attr.type}'") Exception: Space 'devlink' has no attribute with value '132' Introduce a command line option "process-unknown" and pass it down to YnlFamily class constructor to allow user to process unknown attributes and types and print them as binaries. $ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/devlink.yaml --do trap-get --json '{"bus-name": "netdevsim", "dev-name": "netdevsim1", "trap-name": "source_mac_is_multicast"}' --process-unknown {'UnknownAttr(129)': {'UnknownAttr(0)': b'\x00\x00\x00\x00\x00\x00\x00\x00', 'UnknownAttr(1)': b'\x00\x00\x00\x00\x00\x00\x00\x00', 'UnknownAttr(2)': b'\x0e\x00\x00\x00\x00\x00\x00\x00'}, 'UnknownAttr(132)': b'\x00', 'UnknownAttr(133)': b'', 'UnknownAttr(134)': {'UnknownAttr(0)': b''}, 'bus-name': 'netdevsim', 'dev-name': 'netdevsim1', 'trap-action': 'drop', 'trap-group-name': 'l2_drops', 'trap-name': 'source_mac_is_multicast'} Signed-off-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20231027092525.956172-1-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-28tools/net/ynl: Add support for create flagsDonald Hunter1-2/+10
Add support for using NLM_F_REPLACE, _EXCL, _CREATE and _APPEND flags in requests. Signed-off-by: Donald Hunter <donald.hunter@gmail.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://lore.kernel.org/r/20230825122756.7603-10-donald.hunter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-08ynl: re-license uniformly under GPL-2.0 OR BSD-3-ClauseJakub Kicinski1-1/+1
I was intending to make all the Netlink Spec code BSD-3-Clause to ease the adoption but it appears that: - I fumbled the uAPI and used "GPL WITH uAPI note" there - it gives people pause as they expect GPL in the kernel As suggested by Chuck re-license under dual. This gives us benefit of full BSD freedom while fulfilling the broad "kernel is under GPL" expectations. Link: https://lore.kernel.org/all/20230304120108.05dd44c5@kernel.org/ Link: https://lore.kernel.org/r/20230306200457.3903854-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-01tools: net: use python3 explicitlyJakub Kicinski1-1/+1
The scripts require Python 3 and some distros are dropping Python 2 support. Reported-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-01tools: ynl: load jsonschema on demandJakub Kicinski1-0/+4
The CLI script tries to validate jsonschema by default. It's seems better to validate too many times than too few. However, when copying the scripts to random servers having to install jsonschema is tedious. Load jsonschema via importlib, and let the user opt out. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-01tools: ynl: use operation names from spec on the CLIJakub Kicinski1-4/+5
When I wrote the first version of the Python code I was quite excited that we can generate class methods directly from the spec. Unfortunately we need to use valid identifiers for method names (specifically no dashes are allowed). Don't reuse those names on the CLI, it's much more natural to use the operation names exactly as listed in the spec. Instead of: ./cli --do rings_get use: ./cli --do rings-get Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-01tools: ynl: move the cli and netlink code aroundJakub Kicinski1-0/+47
Move the CLI code out of samples/ and the library part of it into tools/net/ynl/lib/. This way we can start sharing some code with the code gen. Initially I thought that code gen is too C-specific to share anything but basic stuff like calculating values for enums can easily be shared. Signed-off-by: Jakub Kicinski <kuba@kernel.org>