Re: To netlink or not to netlink, that is the question

[Dan Williams <dcbw@redhat.com>]

On Thu, 2017-01-12 at 19:28 +0100, Jason A. Donenfeld wrote:
> On Thu, Jan 12, 2017 at 6:14 PM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > It is up to you but I doubt that code with new private ioctl's will
> > be
> > accepted upstream. If you want full review then post for inclusion
> > upstream.
> > If you just want to maintain it is a private fork, go ahead and do
> > what
> > you want and suffer the consequences.
> 
> Obviously I'm going for upstream conclusion and not willing to
> "suffer
> the consequences", hence my email in the first place. Given that you
> seem most interested in netlink, might you have any constructive
> suggestions on how netlink might be used with very large atomic
> messages?

Typically kernel code doesn't pass very large atomic messages back and
forth.  From the description you mailed, I would guess a better fit API
would be to have specific netlink mechanisms for add/remove wgpeers,
and a specific mechanism for add/remove ipmasks for each peer.  And
don't forget netlink events to indicate when peers and ipmasks have
been added/removed, so userspace is aware of that.

Besides, perhaps multiple programs may wish to manipulate a wgdevice,
which could include adding/removing peers or ipmasks from separate
userspace processes.  That's not really possible with a huge buffer
that includes all the information, as a process would have to read the
buffer, update it, and send it back, which would then potentially
clobber whatever another process did between the read/write.

In short, if the API doesn't quite fit, then perhaps the API could be
broken up into smaller, more discrete operations that better fit the
netlink API.

Just some thoughts...

Dan