Hi, 在 2017年05月16日 21:12, Toke Høiland-Jørgensen 写道: > "Jason A. Donenfeld" <[email protected]> writes: > >> Hey guys, >> >> Currently wg(8) talks to the kernel by passing structs through an >> ioctl. Due to upstream demands, this is going to be changed to >> netlink, and we'll ditch those structs. wg(8) previously tried to >> re-use those same structs for userspace implementations, passing them >> through a unix socket. Implementors did not like dealing with this. >> Since the structs are going for the kernel stuff, we might as well >> move to something better, too, for the userspace stuff. Therefore >> wg(8) now has a very simple text-based IPC format over unix sockets >> (or Windows named pipes) that can be easily implemented in nearly >> every language, even bash. >> >> I've written a small description of it here: https://www.wireguard.io/xplatform/ >> >> This will be part of the next snapshot. >> >> Any questions?
Good! 😄. In the “configuration protocol” section, I think “wg(8) responds to ...” should be “An userspace implementation respondes to ...”? A text based format is certainly easier to deal with than C structs. Hope I can find some time to finally implement it in WireGuard.rs. That said, I still like the idea that an userspace implementation being usable without wg(8): it just takes a configuration and runs it, simple and straightforward. > > I applaud the general idea of moving to a text-based interface. But why > invent Yet Another Configuration Format? > > I guess you could say that key=value pairs are fairly straight forward; > but from the examples it looks like there's an implicit nested > structure? I.e. a public_key=xxx line denotes the start of a new > endpoint, and the following keys are logically part of that endpoint? > Or? If this is the case, you'll need a stateful parser to parse it, > which is not immediately obvious from the description, and is bound to > trip people up at some point... > > So why not avoid any possible confusion and just emit JSON? Or another > well-established serialisation format where the nesting can be made > explicit... :) +1 for well-established serialisation format. Guanhao Yin _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
