From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: toke@toke.dk Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 81eba860 for ; Tue, 16 May 2017 13:01:27 +0000 (UTC) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id e535a970 for ; Tue, 16 May 2017 13:01:27 +0000 (UTC) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: "Jason A. Donenfeld" Subject: Re: Text-based IPC for Userspace Implementations References: Date: Tue, 16 May 2017 15:12:39 +0200 In-Reply-To: (Jason A. Donenfeld's message of "Tue, 16 May 2017 14:36:00 +0200") Message-ID: <87vap1gd2w.fsf@alrua-kau> MIME-Version: 1.0 Content-Type: text/plain Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , "Jason A. Donenfeld" 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? 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... :) -Toke