STRUCT ETHNL_REQUEST_OPS(9)

💅 struct ethnl_request_ops(9) — Kernel API Manual, but make it make sense

okay bestie, sit down, grab a strawberry 🍓, because this one's a kernel netlink page and I promise it's actually iconic once you see it. this is struct ethnl_request_ops — the glow-up that gives you unified handling of GET and SET requests ✨

---

✨ SYNOPSIS ✨

struct ethnl_request_ops {
    u8 request_cmd;
    u8 reply_cmd;
    u16 hdr_attr;
    unsigned int            req_info_size;
    unsigned int            reply_data_size;
    bool allow_nodev_do;
    u8 set_ntf_cmd;
    int (*parse_request)(struct ethnl_req_info *req_info, const struct
genl_info *info, struct nlattr **tb, struct netlink_ext_ack *extack);
    int (*prepare_data)(const struct ethnl_req_info *req_info, struct
ethnl_reply_data *reply_data, const struct genl_info *info);
    int (*reply_size)(const struct ethnl_req_info *req_info, const
struct ethnl_reply_data *reply_data);
    int (*fill_reply)(struct sk_buff *skb, const struct ethnl_req_info
*req_info, const struct ethnl_reply_data *reply_data);
    void (*cleanup_data)(struct ethnl_reply_data *reply_data);
    int (*set_validate)(struct ethnl_req_info *req_info, struct
genl_info *info);
    int (*set)(struct ethnl_req_info *req_info, struct genl_info *info);
 };

---

🎀 Members 🎀

like, every field, no skips, no "you'll figure it out" energy 🫶

• request_cmd — the command id for the request (GET) 👑
• reply_cmd — the command id for the reply (GET_REPLY)
• hdr_attr — the attribute type for the request header
• req_info_size — the size of request info
• reply_data_size — the size of reply data
• allow_nodev_do — lets you do a non-dump request with no device identification. ⚠️ and listen: locks (rtnl_lock etc.) are only taken if the device is set. like, that's the whole catch, don't forget it 💀
• set_ntf_cmd — the notification to generate on changes (SET) 🔔
• parse_request — parses the request, except for the common header (struct ethnl_req_info). lowkey love this one: the common header is already filled on entry, and everything after it up to repdata_offset is zero initialized. this callback should only modify the type-specific request info using attributes parsed from the request message. it's called for both GET and SET. and the info parsed for SET gets conveyed to the req_info used during NTF generation, iykyk 🧚
• prepare_data — retrieves and prepares the data you need to compose a reply message. calls to ethtool_ops handlers are limited to this callback — that's the rule, periodt. the common reply data (struct ethnl_reply_data) is filled on entry, and the type-specific part after it is zero initialized. this callback should only modify the type-specific part of the reply data. device identification from struct ethnl_reply_data is to be used as for dump requests — it iterates through network devices while the dev member of struct ethnl_req_info points to the device from the client request 🌸
• reply_size — estimates the reply message size. the returned value must be sufficient for the message payload without the common reply header. the callback may return an estimate higher than the actual message size if an exact calculation wouldn't be worth the saved memory space — and honestly? respect, sometimes close enough is slay ✨
• fill_reply — fills the reply message payload (except for the common header) from the reply data. the callback must not generate more payload than the previously called ->reply_size estimated. no overachieving here, bestie 🙈
• cleanup_data — optional cleanup, called when the reply data is no longer needed. you can use it e.g. to free any additional data structures outside the main structure that were allocated by ->prepare_data. when processing dump requests, ->cleanup is called for each message 🧹
• set_validate — checks if a set operation is supported for a given device, and does extra input checks. expected return values:
  • 0 if the operation is a noop for the device (rare 👀)
  • 1 if the operation should proceed to calling set
  • a negative errno on errors

it's called without any locks — just a reference on the netdev. no cap.

• set — executes the set operation. the implementation should return:
  • 0 if no configuration has changed
  • 1 if configuration changed and a notification should be generated
  • a negative errno on errors

---

🌈 Description 🌈

this is the description of the variable parts of GET request handling when you're using the unified infrastructure. the way it works: when you use it, you add a pointer to an instance of this structure to the ethnl_default_requests array, and use the generic handlers ethnl_default_doit, ethnl_default_dumpit, ethnl_default_start and ethnl_default_done in ethtool_genl_ops. then ethnl_default_notify can be used in ethnl_notify_handlers to send notifications of the corresponding type 🔥

---

🦋 SEE ALSO 🦋

kernel file ./net/ethtool/netlink.h, ethnl_strz_size(9), ethnl_put_strz(9), ethnl_update_u32(9), ethnl_update_u8(9), ethnl_update_u8_u32(9), ethnl_update_bool32(9), ethnl_update_bool(9), ethnl_update_binary(9), ethnl_update_bitfield32(9), ethnl_reply_header_size(9), struct ethnl_req_info(9), ethnl_req_get_phydev(9), struct ethnl_reply_data(9)

---

and that's the whole vibe check 💖 this page comes to you from ./net/ethtool, dated October 2026 — that's the source and the date, both accounted for, don't @ me 😌 go forth and unify those GET and SET requests, bestie. mwah. 🎀💅