linux-kernel - Re: [PATCH v3] Add MO(mod objs) variable to process ext modules with subdirs

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: Thu, 11 Apr 2024 21:25:35 +0200
From: Nicolas Schier <nicolas@...sle.eu>
To: "Daniel Walker (danielwa)" <danielwa@...co.com>
Cc: Nicolas Schier <n.schier@....de>,
 "Valerii Chernous -X (vchernou - GLOBALLOGIC INC at Cisco)"
 <vchernou@...co.com>, Masahiro Yamada <masahiroy@...nel.org>,
 Nathan Chancellor <nathan@...nel.org>,
 "xe-linux-external(mailer list)" <xe-linux-external@...co.com>,
 Jonathan Corbet <corbet@....net>,
 "linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
 "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] Add MO(mod objs) variable to process ext modules with
 subdirs

On Thu, Apr 11, 2024 at 05:27:42PM +0000 Daniel Walker (danielwa) wrote:
> On Thu, Apr 11, 2024 at 01:38:20PM +0200, Nicolas Schier wrote:
> > Hi Valerii,
> > 
> > thanks for your patch.  I know several non-upstream kernel developers
> > that would like to see support for out-of-source builds of external
> > kmods (and we developed several work-arounds at AVM as well); but please
> > be aware that patches that don't fix or enhance the in-tree kernel/kmod
> > build but only add feature for out-of-tree stuff, are rarely accepted.

"out-of-tree stuff" was meant to be "out-of-tree kernel modules".  "Rarely" was
chosen in explicit contrast to "never", but to hint on my personal expectation
regarding the probability of acceptance.

> If that were true we would not have driver/uio/ for example. It seems like
> Cisco and NVM should work together produce a solution.
> 
> You could run into this issue even with entirely in tree modules. For example,
> we may have a v6.6 kernel but we need some modules from v5.15 for some incompatibility
> reason in v6.6. Then we may build the v5.15 modules as out of tree modules
> against the v6.6 kernel.

If your in-tree module in question does compile and run properly in v5.15 and
in v6.6: why don't you just compile it in-tree in v6.6?  Which driver/module do
you refer to?

> You also have just normal developers making kernel modules which always start as
> out of tree modules before they are upstreamed. Those modules could be any level
> of complexity.

I do not agree, but there is no need to convince me as I am not in the position
to decide between acceptance or denial.  I just thought it might be fair to
warn that I do not expect acceptance.

Kind regards,
Nicolas



> I don't think it make sense to view this as strictly enhancing large of the tree
> modules with no upstream potential.
> 
> Daniel

-- 
epost|xmpp: nicolas@...sle.eu          irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
     -- frykten for herren er opphav til kunnskap --

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)