<< I'm very much in favour of this (updating `setconf` to use this new syncronisation approach), if anything it feels more logical and is how I initially (wrongly) assumed `setconf` behaved when starting out with WireGuard a while back. >>
+1 ... it's better to keep the same command if its definition can be expanded (fewer things to remember and less mental clutter) p.s. does this overlap with similar planned in wg-dynamic? On Tue, Jun 11, 2019 at 5:23 PM Steven Honson <ste...@honson.id.au> wrote: > On Wed, 12 Jun 2019, at 3:56 AM, Jason A. Donenfeld wrote: > > The other thing I was wondering is: aside from performance and races > > as described above, why not just make this the functionality of > > `setconf`? Then there's be no need to introduce a new subcommand. In > > otherwords, the idea would be to make `setconf` not destroy existing > > peers if we're going to be re-adding them again. > > I'm very much in favour of this (updating `setconf` to use this new > syncronisation approach), if anything it feels more logical and is how I > initially (wrongly) assumed `setconf` behaved when starting out with > WireGuard a while back. > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard >
_______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
