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]
Message-ID: <ZhgdjpE+yl3IYSzl@goliath>
Date: Thu, 11 Apr 2024 17:27:42 +0000
From: "Daniel Walker (danielwa)" <danielwa@...co.com>
To: Nicolas Schier <n.schier@....de>
CC: "Valerii Chernous -X (vchernou - GLOBALLOGIC INC at Cisco)"
	<vchernou@...co.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nathan
 Chancellor <nathan@...nel.org>,
        Nicolas Schier <nicolas@...sle.eu>,
        "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 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.
> 

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.

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 don't think it make sense to view this as strictly enhancing large of the tree
modules with no upstream potential.

Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ