On Thu, 2017-01-12 at 19:28 +0100, Jason A. Donenfeld wrote: > On Thu, Jan 12, 2017 at 6:14 PM, Stephen Hemminger > <step...@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
