Date: Fri, 12 Apr 2024 08:34:31 +0200
From: Nicolas Schier <nicolas@...sle.eu>
To: "Daniel Walker (danielwa)" <danielwa@...co.com>
Cc: "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 08:50:10PM +0000, Daniel Walker (danielwa) wrote:
> On Thu, Apr 11, 2024 at 09:25:35PM +0200, Nicolas Schier wrote:
> > On Thu, Apr 11, 2024 at 05:27:42PM +0000 Daniel Walker (danielwa) wrote:
[...]
> > > 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.
>  
> All problems should be fixed or worked around. One bit of code maybe isn't
> the best choice or maybe another is, but not fixing or working around the
> problem is not really an option.

Let me sum up: It is possible to build out-of-tree kmods with subdirs
in their source tree.
The patch attempts to put support for _out-of-source builds_ of
out-of-tree kmods with subdirs into kbuild itself.

If you really out-of-source builds for your complex out-of-tree kmods,
than, as a "work-around", you can simply put those 'src' override lines
into your oot-Kbuild files.  But you probably know that already, right?

> > 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?
> 
> I believe it was this driver drivers/crypto/marvell/octeontx2 . I don't recall
> every aspect of the issues but it has to do with what Marvell supported in their
> SDK and the exact hardware we were using and the bootloader we had on the
> product.
> 
> > > 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.
> 
> I think it's incorrect, unhealthy even, to look at it that way. If your using
> Linux to make a product and you have an issue, it should be consider as a real
> issue. Not something maintainer can just discard. Unless the maintainer has
> a suggestion to do what is needed or different code to do it.
> 
> Daniel

Daniel,

I am confused about the outcome from your argumentation that you might
expect.  And I think, I as a spare-time reviewer (not maintainer), am
not the one you want to argue with.

If you have a concrete technical issue or bug, please explain it
concretely to linux-kbuild and we will probably find someone trying to
help you.  If you want me to hide critical thoughts when reviewing
patches under your pillow, then please tell me so.

Have a nice weekend,
Nicolas

Powered by blists - more mailing lists