All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Korsgaard <peter@korsgaard.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 0/2] package/wireguard upgrade
Date: Thu, 09 Jan 2020 10:15:47 +0100	[thread overview]
Message-ID: <87imllgfcs.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <20200108210929.GD17943@scaer> (Yann E. MORIN's message of "Wed,  8 Jan 2020 22:09:29 +0100")

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Peter, All,
 > On 2020-01-06 11:47 +0100, Peter Korsgaard spake thusly:
 >> With the kernel support for WireGuard getting mainlined, the upstream repo
 >> has been split in a wireguard-tools repo for the userspace tooling and
 >> wireguard-linux-compat for the kernel side (for 3.10+ legacy kernels).
 >> 
 >> This series changes the wireguard package to use the wireguard-tools
 >> repo and adds a package for wireguard-linux-compat.

 > So, previously, selecting BR2_PACKAGE_WIREGUARD would build both the
 > kernel module and the userland tools, as they were packagesd in a single
 > upstream package.

Yes, if the configuration builds a Linux kernel.


 > Now, they are separated into two different upstream packages, namely
 > wireguard-tools and wireguard-linux-compat.

 > With your patchset, an existing defconfig will now only build the
 > userland tools, even if the user would still need the kernel module for
 > older kernels.

 > So, my proposal would be to have a single patch that introduces the
 > split, with a renaming of the existing wireguard package, and a legacy
 > symbol that selects both the userland tools and the compat module.

I don't think there is any specific reason why it all HAS to be done in
a single commit?


 > This would allow existing configs to stay to iso-functionality. Thanks
 > to the legacy handling, the user will notice and will have to confirm
 > they still need/want the kernel module, and they can disable it if not.

The symbol rename is a bit more noisy, but it indeed is nicer for users
of the legacy kernel module.

Thanks, I've sent a v2 implementing that.
-- 
Bye, Peter Korsgaard

      reply	other threads:[~2020-01-09  9:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-06 10:47 [Buildroot] [PATCH 0/2] package/wireguard upgrade Peter Korsgaard
2020-01-06 10:47 ` [Buildroot] [PATCH 1/2] package/wireguard: change to the wireguard-tools package Peter Korsgaard
2020-01-06 10:47 ` [Buildroot] [PATCH 2/2] package/wireguard-linux-compat: new package Peter Korsgaard
2020-01-08 21:09 ` [Buildroot] [PATCH 0/2] package/wireguard upgrade Yann E. MORIN
2020-01-09  9:15   ` Peter Korsgaard [this message]

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=87imllgfcs.fsf@dell.be.48ers.dk \
    --to=peter@korsgaard.com \
    --cc=buildroot@busybox.net \
    /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.