linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Netdev <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v1 3/3] net: WireGuard secure network tunnel
Date: Fri, 3 Aug 2018 16:39:36 +0200	[thread overview]
Message-ID: <20180803143936.GD27445@lunn.ch> (raw)
In-Reply-To: <CAHmME9oWYD7TUSkbqAFRFk9kwSWDfC2h-J72gpdxJiw5i1yrXw@mail.gmail.com>

On Fri, Aug 03, 2018 at 02:35:40AM +0200, Jason A. Donenfeld wrote:
> On Tue, Jul 31, 2018 at 10:02 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > I just gave this patch to checkpatch.pl...
> On Tue, Jul 31, 2018 at 10:22 PM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > Please break lines at something reasonable like 100 characters.
> 
> If the long lines really truly are dreadful, I have no problem fixing
> that up for v2.

A very large percentage of the kernel code uses 80 characters maximum.
So anything which does not makes it look different. It makes it not
look like kernel code. It is also not just about styling. If you use
long lines, it makes it easier to use more indentation levels. But
good readable code tends to have lots of little functions with only
one or two levels of indentation, and each function does just one
easily understood thing.

Plus this is pretty much an open invite for kernel newbies to submit
patches fixing up all these warnings. Maybe you would prefer to do it
yourself, so you keep some degree of control over it. Also, such white
space changes make backporting fixes more difficult. So it is better
if you can get this done before it lands in the kernel and backporting
becomes necessary.

> On Tue, Jul 31, 2018 at 10:02 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > > +static __always_inline void swap_endian(u8 *dst, const u8 *src, u8 bits)
> > There is a general preference to not force the compile to
> > inline. Leave it to decide.
> 
> I'm aware this is for the most part the case, and I've read the
> variety of threads and documentation of folks explaining why this is a
> good policy. In the particular instance of that function, inlining is
> in fact always the right thing to do. But I'll give it a double check
> to see if the compiler is already figuring that out on its own.

Well, what compiler are you going to check? I think the minimum
version of GCC is now v4.5. So you probably want to check 8.2, 7.3,
6.4, 5.5, 4.9.3 and 4.8. And you might want to check ARM, MIPs, x86
and amd64. So only 24 versions.

More realistically, if you have a strong argument why a particular
function must be inlined, e.g. to avoid a timing attack, make that
argument.

	Andrew

  reply	other threads:[~2018-08-03 14:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-31 19:10 [PATCH v1 0/3] WireGuard: Secure Network Tunnel Jason A. Donenfeld
2018-07-31 19:11 ` [PATCH v1 1/3] random: Make crng state queryable Jason A. Donenfeld
2018-08-02 21:35   ` Theodore Y. Ts'o
2018-07-31 19:11 ` [PATCH v1 3/3] net: WireGuard secure network tunnel Jason A. Donenfeld
2018-07-31 20:02   ` Andrew Lunn
2018-07-31 20:22   ` Stephen Hemminger
2018-07-31 20:27   ` Stephen Hemminger
2018-08-03  0:35     ` Jason A. Donenfeld
2018-08-03 14:39       ` Andrew Lunn [this message]
2018-08-01  1:21   ` Shawn Landden
2018-08-13 15:40 ` [PATCH v1 0/3] WireGuard: Secure Network Tunnel James Bottomley
2018-08-13 15:53   ` Willy Tarreau
2018-08-13 17:02   ` Jason A. Donenfeld
2018-08-13 17:37     ` James Bottomley
2018-08-13 17:55       ` Jason A. Donenfeld
2018-08-13 18:04         ` James Bottomley

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=20180803143936.GD27445@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=Jason@zx2c4.com \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    /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).