On Fri, Apr 12, 2024 at 08:34:31AM +0200, Nicolas Schier wrote: > 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? I tried "make src=..." and Valerii also tried it. I think that's what your referring to. There must have been a defect added which prevents that from working. It has some sort of recursion issue. It seems this method was not "official" and only work by accident. > > > 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. I don't care if your a maintainer or not. > 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. I don't think it's critical thinking to effectively tell someone to stop submitting code. Daniel
