linux-kernel - Re: [PATCH v2] qede: remove linux/version.h and linux/compiler.h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 14 Mar 2023 12:13:23 +0100
From:   Simon Horman <simon.horman@...igine.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Dan Carpenter <error27@...il.com>,
        Alexander Lobakin <aleksander.lobakin@...el.com>,
        Muhammad Usama Anjum <usama.anjum@...labora.com>,
        Ariel Elior <aelior@...vell.com>,
        Manish Chopra <manishc@...vell.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>, kernel@...labora.com,
        kernel-janitors@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] qede: remove linux/version.h and linux/compiler.h

On Mon, Mar 13, 2023 at 11:45:38AM -0700, Jakub Kicinski wrote:
> On Mon, 13 Mar 2023 11:46:57 +0300 Dan Carpenter wrote:
> > This is only for networking.
> > 
> > It affect BPF too, I suppose, but I always tell everyone to just send
> > BPF bug reports instead of patches.  I can keep track of linux-next, net
> > and net-next.  No one can keep track of all @#$@#$@#$@# 300+ trees.
> > 
> > I really hate this networking requirement but I try really hard to get
> > it right and still mess up half the time.
> 
> Don't worry about it too much, there needs to be a level of
> understanding for cross-tree folks. This unfortunately may 
> not be afforded to less known developers.. because we don't 
> know them/that they are working cross-tree.
> 
> Reality check for me - this is really something that should
> be handled by our process scripts, right? get_maintainer/
> /checkpatch ? Or that's not a fair expectation.

I think that what we are seeing is friction introduced by our processes.

I'd say that for those who spend time contributing to net-next/net
on a regular basis, the friction is not great. The process is learnt.
And for the most part followed.

But for others, developers more focused on other parts of the Kernel,
or otherwise contributing to net-next/net infrequently, the friction
seems real.

I do think tooling can help.
But perhaps we can also explore other ways to reduce friction:

* Aligning processes with those of other parts of the Kernel
* Streamlining processes
* providing an alternate path for contributions of the nature
  I described above.

Just ideas, seeing as you asked.