On Fri, 2020-10-02 at 13:50 -0700, Jakub Kicinski wrote:
>
> My thinking was that until kernel actually start using separate dump
> policies user space can assume policy 0 is relevant. But yeah, merging
> your changes first would probably be best.
Works for me. I have it based on yours. Just updated my branch (top
commit is 4d5045adfe90), but I'll probably only actually email it out
once things are a bit more settled wrt. your changes.
> I, OTOH, am having second thoughts about not implementing separate
> policies for dump right away, since Michal said he'll need them soon :)
:)
> Any ideas on how to do that cleanly? At some point it will make sense
> to have dumps and doits in separate structures, as you said earlier,
> but can we have "small" and "full" ops for both? That seems like too
> much :/
Not sure I understand what you just wrote :)
I had originally assumed dumps would be "infrequent", and so having the
small ops without dumps would be worthwhile. You said it wasn't true for
other users, so small ops still have .doit and .dumpit entries. Which is
fine?
But in the small ops anyway you don't have a policy pointer - I guess
you could have two "fallbacks" (for do and dump) in the family rather
than just one?
Another option - though it requires some rejiggering in my new policy
dump code - would be to key the lookup based on do/dump as well. Then
you could have the *same* op listed twice like
struct genl_ops my_ops[] = {
{
.cmd = SOMETHING,
.doit = do_something,
.policy = something_do_policy,
},
{
.cmd = SOMETHING,
.dumpit = dump_something,
.policy = something_dump_policy,
},
};
That way you only pay where needed? But ultimately with large ops you
already pay for the start/dump/done pointers, and you'd have that even
for the extra entry with _doit_ because ...
Unless we put three different kinds of ops (small, full-do, full-dump),
but that gets a bit awkward too?
johannes
