From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: David Ahern <dsahern@gmail.com>, "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Netdev <netdev@vger.kernel.org>,
WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: organization of wireguard linux kernel repos moving forward
Date: Mon, 09 Dec 2019 17:36:07 +0100 [thread overview]
Message-ID: <875zipihhk.fsf@toke.dk> (raw)
In-Reply-To: <8a5bdf0f-c7f8-4667-ecba-ecb671bea2e5@gmail.com>
David Ahern <dsahern@gmail.com> writes:
> 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.
Thought that might be the case :)
That means a re-implementation, then. In which case the question becomes
whether it's better to do it as an 'ip' subcommand (or even just new
parameters to 'ip link'), or a new top-level utility striving for
compatibility with 'wg'. But that's mostly a UI issue...
-Toke
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
WARNING: multiple messages have this Message-ID (diff)
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: David Ahern <dsahern@gmail.com>, "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>,
Netdev <netdev@vger.kernel.org>,
Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: organization of wireguard linux kernel repos moving forward
Date: Mon, 09 Dec 2019 17:36:07 +0100 [thread overview]
Message-ID: <875zipihhk.fsf@toke.dk> (raw)
In-Reply-To: <8a5bdf0f-c7f8-4667-ecba-ecb671bea2e5@gmail.com>
David Ahern <dsahern@gmail.com> writes:
> 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.
Thought that might be the case :)
That means a re-implementation, then. In which case the question becomes
whether it's better to do it as an 'ip' subcommand (or even just new
parameters to 'ip link'), or a new top-level utility striving for
compatibility with 'wg'. But that's mostly a UI issue...
-Toke
next prev parent reply other threads:[~2019-12-09 16:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-09 11:56 organization of wireguard linux kernel repos moving forward Jason A. Donenfeld
2019-12-09 11:56 ` Jason A. Donenfeld
2019-12-09 12:43 ` Toke Høiland-Jørgensen
2019-12-09 12:43 ` Toke Høiland-Jørgensen
2019-12-09 12:49 ` Jason A. Donenfeld
2019-12-09 12:49 ` Jason A. Donenfeld
2019-12-09 16:01 ` Toke Høiland-Jørgensen
2019-12-09 16:01 ` Toke Høiland-Jørgensen
2019-12-09 16:18 ` David Ahern
2019-12-09 16:18 ` David Ahern
2019-12-09 16:36 ` Toke Høiland-Jørgensen [this message]
2019-12-09 16:36 ` Toke Høiland-Jørgensen
2019-12-26 17:45 ` Jason A. Donenfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875zipihhk.fsf@toke.dk \
--to=toke@toke.dk \
--cc=Jason@zx2c4.com \
--cc=dsahern@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.