Subject: Re: [PATCH 1/4] rust: netlink: add raw netlink abstraction

From: Alice Ryhl <[email-masked]>
Date: Mon, 9 Mar 2026 08:38:02 +0000

On Sun, Mar 08, 2026 at 06:24:16PM +0100, Andrew Lunn wrote:
> > If that is the case, then it sounds like the correct API design would be
> > to have a separate NetlinkSkBuff type so that you cannot mix them up
> > with an sk_buff used for packet data.
> > 
> > > So, maybe you can have a base definition of skbuff in rust/kernel/net,
> > > and build on top of that to make a netlink specific skbuff, with a
> > > limited list of methods which can access it, those needed for netlink?
> > > Make use of the Rust type system? And leave the messy fast path packet
> > > data things for somebody else.
> > 
> > That makes sense to me. If there is duplication between the two sk_buff
> > types, then one can be defined in terms of the other (or maybe it's
> > easier to not do that).
> 
> Probably struct sk_buff is one of those complex things where we make
> our best guess design now, and be prepared to redesign and refactor
> the code as we learn more. To me, it feels like we need a base SkBuff
> with full access to all API methods. And then a restricted type for
> NetlinkSkBuff on top of that for users of netlink.

Agreed. Though in this patchset, I don't believe I use any of the base
skbuff methods, except for the fact that the nlmsg methods seem to wrap
them. So it is probably dead code to add much right now unless I bypass
the nlmsg wrappers.

Alice