Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 11 Apr 2024 21:25:35 +0200 | From | Nicolas Schier <> | 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@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- [unhandled content-type:application/pgp-signature] | ![\](/images/icornerr.gif) |