On Wed, 30 Sep 2020 18:17:47 +0200 Johannes Berg wrote: > On Wed, 2020-09-30 at 18:06 +0200, Johannes Berg wrote: > > > > That's the historic info I guess - I'll take a look at ethtool later and > > see what it's doing there. > > Oh, ok, I see how that works ... you *do* have a sort of common/aliased > attribute inside each per-op family that then carries common sub- > attributes. That can be linked into the policy. > > I guess that's not a bad idea. I'd still prefer not to add > maxattr/policy into the ops struct because like I said, that's a large > amount of wasted space? > > Perhaps then a "struct nla_policy *get_policy(int cmd, int *maxattr)" > function (method) could work, and fall back to just "->policy" and"- > >maxattr" if unset, and then you'd just have to write a few lines of > code for this case? Seems like overall that'd still be smaller than > putting the pointer/maxattr into each and every op struct.
I started with a get_policy() callback, but I didn't like it much. Static data is much more pleasant for a client of the API IMHO. What do you think about "ops light"? Insufficiently flexible?
