Le 13/01/2017 à 08:17, Johannes Berg a écrit :
[snip]
> In addition to what others have said - netlink typically includes (and
> has helpers to do so) a generation counter that's updated whenever this
> list changes, and included in each message, so if userspace really
> cares (often not) it can re
On Thu, 2017-01-12 at 20:02 +0100, Jason A. Donenfeld wrote:
> Hi Dan,
>
> Thanks for your response. I'd thought about this, at least for
> adding/removing wgpeers/wgipmasks and for configuring wgdevices. This
> would fit into multiple smaller messages indeed.
>
> But what about fetching the list
From: "Jason A. Donenfeld"
Date: Thu, 12 Jan 2017 21:07:43 +0100
> David - you concur with Stephen that ioctl is really not okay and I
> should absolutely do netlink?
Yes.
On Thu, Jan 12, 2017 at 8:11 PM, David Miller wrote:
> This is a fact of life, dumps are always chopped into suitable
> numbers of responses as necessary. We do this for IPV4 routes,
> network interfaces, etc. and it all works out just fine.
>
> The thing you should be asking yourself is, if some
From: "Jason A. Donenfeld"
Date: Thu, 12 Jan 2017 20:02:14 +0100
> But what about fetching the list of all existing peers and ipmasks
> atomically? It seems like with multiple calls, if I'm using some kind
> of pagination, things could change in the process. That's why using
> one big buffer was
Hi Dan,
Thanks for your response. I'd thought about this, at least for
adding/removing wgpeers/wgipmasks and for configuring wgdevices. This
would fit into multiple smaller messages indeed.
But what about fetching the list of all existing peers and ipmasks
atomically? It seems like with multiple
On Thu, 2017-01-12 at 19:28 +0100, Jason A. Donenfeld wrote:
> On Thu, Jan 12, 2017 at 6:14 PM, Stephen Hemminger
> 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
On Thu, 12 Jan 2017 14:01:07 +0100
"Jason A. Donenfeld" wrote:
> Hey folks,
>
> A few months ago I switched away from using netlink in wireguard,
> preferring instead to use ioctl. I had come up against limitations in
> rtnetlink, and ioctl presented a straightforward hard to screw-up
> alternat
On Thu, Jan 12, 2017 at 6:14 PM, Stephen Hemminger
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
Hey folks,
A few months ago I switched away from using netlink in wireguard,
preferring instead to use ioctl. I had come up against limitations in
rtnetlink, and ioctl presented a straightforward hard to screw-up
alternative. The very simple API is documented here:
https://git.zx2c4.com/WireGuard/
10 matches
Mail list logo
