Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: wireguard@lists.zx2c4.com
Cc: 894909@bugs.debian.org
Subject: Re: making wireguard work on RHEL7/etc.
Date: Thu, 05 Apr 2018 12:15:44 -0400	[thread overview]
Message-ID: <87bmexy6hb.fsf@fifthhorseman.net> (raw)
In-Reply-To: <87k1tly9ln.fsf@fifthhorseman.net>

On Thu 2018-04-05 11:08:20 -0400, Daniel Kahn Gillmor wrote:
> On Tue 2017-06-27 13:08:14 +0200, Jason A. Donenfeld wrote:
>> compat.h is a dumpster fire already. Tons of people use the RHEL kernel.
>> I think supporting it won't make an already gross cess pool any more
>> disgusting. It's a file of hacks; I might as well add another.
>>
>> (I probably won't add hacks, though, for the heaps of random custom
>> Android vendor kernels.)
>
> sorry to dredge this thread back up from the archives...
>
> https://bugs.debian.org/894909 shows someone trying to build wireguard
> against the debian 8 ("jessie" aka "oldstable") 3.16 kernel saying that
> they needed a similar patch to make the kernel module build.
>
> I know that debian's kernel team does backport a lot of fixes to our
> supported older kernels, similar to older releases of RedHat.
>
> i'm asking over on #debian-kernel (on OFTC) to see whether there is some
> similar to RHEL_MAJOR or CONFIG_SUSE_KERNEL or UTS_UBUNTU_RELEASE_ABI
> that we can use for jessie.

Ben Hutchings of the debian kernel team followed up there suggesting
feature tests or autoconf-type checks:

11:02 < dkg> https://bugs.debian.org/894909 suggests that some of the
             backported fixes to 3.16 in jessie are getting in the way
             of compiling wireguard.  the referenced upstream thread
             shows that they worked around the problem for RHEL7 using
             some redhat-specific #defines
11:02 -zwiebelbot:#debian-kernel- Debian#894909: wireguard-dkms:
                                  dev_recursion_level definition problem
                                  - https://bugs.debian.org/894909
11:02 < dkg> is there a comparable fix for older debian kernels?
11:04 < dkg> they have tests for #if RHEL_MAJOR == 7
11:04 < dkg> and #ifdef UTS_UBUNTU_RELEASE_ABI
11:52 < bwh> dkg: I've been there, and the way to deal with this is autoconf-type checks
11:55 < bwh> Well, either '#ifdef feature' or an autoconf-type check

So i don't think there's a comparable #define we can use for the
maintained debian kernels :/

i don't know how dev_recursion_level works.  can we wrap the #define
dev_recursion_level() 0 inside an #ifndef dev_recursion_level safely?

           --dkg

      reply	other threads:[~2018-04-05 16:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-24 15:18 wireguard
2017-06-26  8:07 ` Aaron Muir Hamilton
2017-06-26  8:19   ` wireguard
2017-06-26  9:04     ` Jason A. Donenfeld
2017-06-26  9:25       ` wireguard
2017-06-26  9:57         ` Jason A. Donenfeld
2017-06-26 10:47           ` Jason A. Donenfeld
2017-06-26 19:55             ` wireguard
2017-06-27 11:02               ` Jason A. Donenfeld
2017-06-26 20:45             ` wireguard
2017-06-27 11:05               ` Jason A. Donenfeld
2017-06-27 11:38                 ` wireguard
2017-06-27 19:23                   ` Jason A. Donenfeld
2017-06-27 19:43                     ` wireguard
2017-06-27 19:59                       ` Jason A. Donenfeld
2017-06-27 20:22                         ` Jason A. Donenfeld
2017-06-27 20:52                           ` Jason A. Donenfeld
2017-06-27 21:30                             ` wireguard
2017-06-27 22:09                               ` Jason A. Donenfeld
2017-06-27  5:35           ` Andrej Kacian
2017-06-27  7:25             ` wireguard
2017-06-27  9:39               ` Andrej Kacian
2017-06-27 11:08                 ` Jason A. Donenfeld
2018-04-05 15:08                   ` Daniel Kahn Gillmor
2018-04-05 16:15                     ` Daniel Kahn Gillmor [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=87bmexy6hb.fsf@fifthhorseman.net \
    --to=dkg@fifthhorseman.net \
    --cc=894909@bugs.debian.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).