[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YvjqLDnWUONvnv3E@shredder>
Date: Sun, 14 Aug 2022 15:27:24 +0300
From: Ido Schimmel <idosch@...sch.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
pabeni@...hat.com, sdf@...gle.com, jacob.e.keller@...el.com,
vadfed@...com, johannes@...solutions.net, jiri@...nulli.us,
dsahern@...nel.org, stephen@...workplumber.org, fw@...len.de,
linux-doc@...r.kernel.org
Subject: Re: [RFC net-next 4/4] ynl: add a sample user for ethtool
On Wed, Aug 10, 2022 at 07:23:04PM -0700, Jakub Kicinski wrote:
> @@ -0,0 +1,115 @@
> +# SPDX-License-Identifier: BSD-3-Clause
> +
> +name: ethtool
> +
> +description: |
> + Ethernet device configuration interface.
> +
> +attr-cnt-suffix: CNT
> +
> +attribute-spaces:
> + -
> + name: header
> + name-prefix: ETHTOOL_A_HEADER_
> + attributes:
> + -
> + name: dev_index
> + val: 1
> + type: u32
> + -
> + name: dev_name
> + type: nul-string
> + len: ALTIFNAMSIZ - 1
> + -
> + name: flags
> + type: u32
> + -
> + name: channels
> + name-prefix: ETHTOOL_A_CHANNELS_
> + attributes:
> + -
> + name: header
> + val: 1
> + type: nest
> + nested-attributes: header
> + -
> + name: rx_max
> + type: u32
> + -
> + name: tx_max
> + type: u32
> + -
> + name: other_max
> + type: u32
> + -
> + name: combined_max
> + type: u32
> + -
> + name: rx_count
> + type: u32
> + -
> + name: tx_count
> + type: u32
> + -
> + name: other_count
> + type: u32
> + -
> + name: combined_count
> + type: u32
Another interesting use case for the schema can be automatic generation
of syzkaller descriptions. These are the corresponding descriptions for
syzkaller:
https://github.com/google/syzkaller/blob/master/sys/linux/socket_netlink_generic_ethtool.txt#L125
Last I checked, these descriptions had to be written by hand, which is
why they are generally out of date, leading to sub-optimal fuzzing. If
schemas are sent along with the kernel code and syzkaller/syzbot
automatically derives descriptions from them, then we should be able to
get meaningful fuzzing as soon as a feature lands in net-next.
> +
> +headers:
> + user: linux/if.h
> + uapi: linux/ethtool_netlink.h
> +
> +operations:
> + name-prefix: ETHTOOL_MSG_
> + async-prefix: ETHTOOL_MSG_
> + list:
> + -
> + name: channels_get
> + val: 17
> + description: Get current and max supported number of channels.
> + attribute-space: channels
> + do:
> + request:
> + attributes:
> + - header
> + reply: &channel_reply
> + attributes:
> + - header
> + - rx_max
> + - tx_max
> + - other_max
> + - combined_max
> + - rx_count
> + - tx_count
> + - other_count
> + - combined_count
> + dump:
> + reply: *channel_reply
> +
> + -
> + name: channels_ntf
> + description: Notification for device changing its number of channels.
> + notify: channels_get
> + mcgrp: monitor
> +
> + -
> + name: channels_set
> + description: Set number of channels.
> + attribute-space: channels
> + do:
> + request:
> + attributes:
> + - header
> + - rx_count
> + - tx_count
> + - other_count
> + - combined_count
> +
> +mcast-groups:
> + name-prefix: ETHTOOL_MCGRP_
> + name-suffix: _NAME
> + list:
> + -
> + name: monitor
Powered by blists - more mailing lists