[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8a5bdf0f-c7f8-4667-ecba-ecb671bea2e5@gmail.com>
Date: Mon, 9 Dec 2019 09:18:20 -0700
From: David Ahern <dsahern@...il.com>
To: "Jason A. Donenfeld" <Jason@...c4.com>,
Toke Høiland-Jørgensen <toke@...e.dk>
Cc: WireGuard mailing list <wireguard@...ts.zx2c4.com>,
Netdev <netdev@...r.kernel.org>,
Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: organization of wireguard linux kernel repos moving forward
On 12/9/19 5:49 AM, Jason A. Donenfeld wrote:
> I'd definitely be interested in this. Back in 2015, that was the plan.
> Then it took a long time to get to where we are now, and since then
> wg(8) has really evolved into its own useful thing. The easiest thing
> would be to move wg(8) wholesale into iproute2 like you suggested;
> that'd allow people to continue using their infrastructure and whatnot
> they've used for a long time now. A more nuanced approach would be
> coming up with a _parallel_ iproute2 tool with mostly the same syntax
> as wg(8) but as a subcommand of ip(8). Originally the latter appealed
> to me, but at this point maybe the former is better after all. I
> suppose something to consider is that wg(8) is actually a
> cross-platform tool now, with a unified syntax across a whole bunch of
> operating systems. But it's also just boring C.
If wg is to move into iproute2, it needs to align with the other
commands and leverage the generic facilities where possible. ie., any
functionality that overlaps with existing iproute2 code to be converted
to use iproute2 code.
Powered by blists - more mailing lists