From: Jiri Pirko <jiri@resnulli.us>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org,
Jakub Kicinski <jakub.kicinski@netronome.com>,
Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
John Linville <linville@tuxdriver.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Johannes Berg <johannes@sipsolutions.net>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v6 09/15] ethtool: generic handlers for GET requests
Date: Thu, 4 Jul 2019 10:49:13 +0200 [thread overview]
Message-ID: <20190704084913.GA18546@nanopsycho> (raw)
In-Reply-To: <4faa0ce52dfe02c9cde5a46012b16c9af6764c5e.1562067622.git.mkubecek@suse.cz>
Tue, Jul 02, 2019 at 01:50:24PM CEST, mkubecek@suse.cz wrote:
[...]
>+/* The structure holding data for unified processing GET requests consists of
>+ * two parts: request info and reply data. Request info is related to client
>+ * request and for dump request it stays constant through all processing;
>+ * reply data contains data for composing a reply message. When processing
>+ * a dump request, request info is filled only once but reply data is filled
>+ * from scratch for each reply message.
>+ *
>+ * +-----------------+-----------------+------------------+-----------------+
>+ * | common_req_info | specific info | ethnl_reply_data | specific data |
>+ * +-----------------+-----------------+------------------+-----------------+
>+ * |<---------- request info --------->|<----------- reply data ----------->|
>+ *
>+ * Request info always starts at offset 0 with struct ethnl_req_info which
>+ * holds information from parsing the common header. It may be followed by
>+ * other members for request attributes specific for current message type.
>+ * Reply data starts with struct ethnl_reply_data which may be followed by
>+ * other members holding data needed to compose a message.
>+ */
>+
[...]
>+/**
>+ * struct get_request_ops - unified handling of GET requests
>+ * @request_cmd: command id for request (GET)
>+ * @reply_cmd: command id for reply (GET_REPLY)
>+ * @hdr_attr: attribute type for request header
>+ * @max_attr: maximum (top level) attribute type
>+ * @data_size: total length of data structure
>+ * @repdata_offset: offset of "reply data" part (struct ethnl_reply_data)
For example, this looks quite scarry for me. You have one big chunk of
data (according to the scheme above) specific for cmd with reply starting
at arbitrary offset.
>+ * @request_policy: netlink policy for message contents
>+ * @header_policy: (optional) netlink policy for request header
>+ * @default_infomask: default infomask (to use if none specified)
>+ * @all_reqflags: allowed request specific flags
>+ * @allow_nodev_do: allow non-dump request with no device identification
>+ * @parse_request:
>+ * Parse request except common header (struct ethnl_req_info). Common
>+ * header is already filled on entry, the rest up to @repdata_offset
>+ * is zero initialized. This callback should only modify type specific
>+ * request info by parsed attributes from request message.
>+ * @prepare_data:
>+ * Retrieve and prepare data needed to compose a reply message. Calls to
>+ * ethtool_ops handlers should be limited to this callback. Common reply
>+ * data (struct ethnl_reply_data) is filled on entry, type specific part
>+ * after it is zero initialized. This callback should only modify the
>+ * type specific part of reply data. Device identification from struct
>+ * ethnl_reply_data is to be used as for dump requests, it iterates
>+ * through network devices which common_req_info::dev points to the
>+ * device from client request.
>+ * @reply_size:
>+ * Estimate reply message size. Returned value must be sufficient for
>+ * message payload without common reply header. The callback may returned
>+ * estimate higher than actual message size if exact calculation would
>+ * not be worth the saved memory space.
>+ * @fill_reply:
>+ * Fill reply message payload (except for common header) from reply data.
>+ * The callback must not generate more payload than previously called
>+ * ->reply_size() estimated.
>+ * @cleanup:
>+ * Optional cleanup called when reply data is no longer needed. Can be
>+ * used e.g. to free any additional data structures outside the main
>+ * structure which were allocated by ->prepare_data(). When processing
>+ * dump requests, ->cleanup() is called for each message.
>+ *
>+ * Description of variable parts of GET request handling when using the unified
>+ * infrastructure. When used, a pointer to an instance of this structure is to
>+ * be added to &get_requests array and generic handlers ethnl_get_doit(),
>+ * ethnl_get_dumpit(), ethnl_get_start() and ethnl_get_done() used in
>+ * @ethnl_genl_ops
>+ */
>+struct get_request_ops {
>+ u8 request_cmd;
>+ u8 reply_cmd;
>+ u16 hdr_attr;
>+ unsigned int max_attr;
>+ unsigned int data_size;
>+ unsigned int repdata_offset;
>+ const struct nla_policy *request_policy;
>+ const struct nla_policy *header_policy;
>+ u32 default_infomask;
>+ u32 all_reqflags;
>+ bool allow_nodev_do;
>+
>+ int (*parse_request)(struct ethnl_req_info *req_info,
>+ struct nlattr **tb,
>+ struct netlink_ext_ack *extack);
>+ int (*prepare_data)(struct ethnl_req_info *req_info,
>+ struct genl_info *info);
>+ int (*reply_size)(const struct ethnl_req_info *req_info);
>+ int (*fill_reply)(struct sk_buff *skb,
>+ const struct ethnl_req_info *req_info);
>+ void (*cleanup)(struct ethnl_req_info *req_info);
>+};
>+
> #endif /* _NET_ETHTOOL_NETLINK_H */
>--
>2.22.0
>
next prev parent reply other threads:[~2019-07-04 8:49 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 11:49 [PATCH net-next v6 00/15] ethtool netlink interface, part 1 Michal Kubecek
2019-07-02 11:49 ` [PATCH net-next v6 01/15] rtnetlink: provide permanent hardware address in RTM_NEWLINK Michal Kubecek
2019-07-02 11:57 ` Jiri Pirko
2019-07-02 14:55 ` Stephen Hemminger
2019-07-02 16:35 ` Michal Kubecek
2019-07-02 11:49 ` [PATCH net-next v6 02/15] netlink: rename nl80211_validate_nested() to nla_validate_nested() Michal Kubecek
2019-07-02 12:03 ` Jiri Pirko
2019-07-02 12:15 ` Johannes Berg
2019-07-02 12:15 ` Johannes Berg
2019-07-02 11:49 ` [PATCH net-next v6 03/15] ethtool: move to its own directory Michal Kubecek
2019-07-02 11:49 ` [PATCH net-next v6 04/15] ethtool: introduce ethtool netlink interface Michal Kubecek
2019-07-02 12:25 ` Jiri Pirko
2019-07-02 14:52 ` Michal Kubecek
2019-07-03 8:41 ` Jiri Pirko
2019-07-08 17:27 ` Michal Kubecek
2019-07-08 18:12 ` Johannes Berg
2019-07-08 19:26 ` Jiri Pirko
2019-07-08 19:28 ` Jiri Pirko
2019-07-08 20:22 ` Michal Kubecek
2019-07-09 13:42 ` Jiri Pirko
2019-07-10 12:12 ` Michal Kubecek
2019-07-03 1:29 ` Jakub Kicinski
2019-07-03 6:35 ` Michal Kubecek
2019-07-02 11:50 ` [PATCH net-next v6 05/15] ethtool: helper functions for " Michal Kubecek
2019-07-02 13:05 ` Jiri Pirko
2019-07-02 16:34 ` Michal Kubecek
2019-07-03 1:28 ` Jakub Kicinski
2019-07-03 10:04 ` Jiri Pirko
2019-07-03 11:13 ` Michal Kubecek
2019-07-08 12:22 ` Michal Kubecek
2019-07-08 14:40 ` Jiri Pirko
2019-07-03 1:37 ` Jakub Kicinski
2019-07-03 7:23 ` Michal Kubecek
2019-07-02 11:50 ` [PATCH net-next v6 06/15] ethtool: netlink bitset handling Michal Kubecek
2019-07-03 11:49 ` Jiri Pirko
2019-07-03 13:44 ` Johannes Berg
2019-07-03 14:37 ` Jiri Pirko
2019-07-04 12:07 ` Johannes Berg
2019-07-03 18:18 ` Michal Kubecek
2019-07-04 8:04 ` Jiri Pirko
2019-07-04 11:52 ` Michal Kubecek
2019-07-04 12:03 ` Johannes Berg
2019-07-04 12:17 ` Michal Kubecek
2019-07-04 12:21 ` Johannes Berg
2019-07-04 12:53 ` Michal Kubecek
2019-07-04 13:10 ` Johannes Berg
2019-07-04 14:31 ` Andrew Lunn
2019-07-09 14:18 ` Jiri Pirko
2019-07-10 12:38 ` Michal Kubecek
2019-07-10 12:59 ` Jiri Pirko
2019-07-10 14:37 ` Michal Kubecek
2019-07-02 11:50 ` [PATCH net-next v6 07/15] ethtool: support for netlink notifications Michal Kubecek
2019-07-03 13:33 ` Jiri Pirko
2019-07-03 14:16 ` Michal Kubecek
2019-07-04 8:06 ` Jiri Pirko
2019-07-03 13:39 ` Johannes Berg
2019-07-03 14:18 ` Michal Kubecek
2019-07-02 11:50 ` [PATCH net-next v6 08/15] ethtool: move string arrays into common file Michal Kubecek
2019-07-03 13:44 ` Jiri Pirko
2019-07-03 14:37 ` Michal Kubecek
2019-07-04 8:09 ` Jiri Pirko
2019-07-02 11:50 ` [PATCH net-next v6 09/15] ethtool: generic handlers for GET requests Michal Kubecek
2019-07-03 14:25 ` Jiri Pirko
2019-07-03 17:53 ` Michal Kubecek
2019-07-04 8:45 ` Jiri Pirko
2019-07-04 8:49 ` Jiri Pirko [this message]
2019-07-04 9:28 ` Michal Kubecek
2019-07-02 11:50 ` [PATCH net-next v6 10/15] ethtool: provide string sets with STRSET_GET request Michal Kubecek
2019-07-04 8:17 ` Jiri Pirko
2019-07-02 11:50 ` [PATCH net-next v6 11/15] ethtool: provide link mode names as a string set Michal Kubecek
2019-07-03 2:04 ` Jakub Kicinski
2019-07-03 2:11 ` Jakub Kicinski
2019-07-03 7:38 ` Michal Kubecek
2019-07-02 11:50 ` [PATCH net-next v6 12/15] ethtool: provide link settings and link modes in SETTINGS_GET request Michal Kubecek
2019-07-02 11:50 ` [PATCH net-next v6 13/15] ethtool: add standard notification handler Michal Kubecek
2019-07-02 11:50 ` [PATCH net-next v6 14/15] ethtool: set link settings and link modes with SETTINGS_SET request Michal Kubecek
2019-07-02 11:50 ` [PATCH net-next v6 15/15] ethtool: provide link state in SETTINGS_GET request Michal Kubecek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190704084913.GA18546@nanopsycho \
--to=jiri@resnulli.us \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=jakub.kicinski@netronome.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.