Re: [linux-yocto] [kernel-cache][PATCH] netfilter: Enable CONFIG_NETFILTER_XT_TARGET_LOG
On 2/15/19 5:13 PM, Tom Rini wrote: > On Fri, Feb 15, 2019 at 10:46:13AM -0500, Bruce Ashfield wrote: > >> merged. >> >> SRCREV updates will be sent out with my next queue. > Thanks. What's the backport policy here? I first ran into this issue > back on Jethro (but that's a fair bit too far to expect a backport to) > and I finally root caused this on thud. Can this go back to thud/sumo I think that depends on kernel versions supported by the stable branches. Maybe patches for each branch for this repo? They need to be posted than accepted/merged. Then I kernel recipes can be updated with the new hashes. - armin > at least on your next round of changes there? > > signature.asc Description: OpenPGP digital signature -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] kernel module override
> 17 feb. 2019 kl. 14:57 skrev Russell Peterson : > > Hello, > > I have what I would think is an unusual requirement regarding a kernel module > and could use some advice. > > I have a kernel module that has been heavily modified... to the point where > we have a separate recipe for it and treat it as an out-of-tree module. This > works by not setting the kernel config file to build that module and our meta > layer builds and installs the module. No problem... works fine for us. > > The problem is that we now want to enable another module that relies on the > module we build out of tree. The issue is that the check config sees we have > not enabled our out of tree module and thus the sanitized config does not > contain this module that we want to enable. If we enable the modified module > in the config file there is, of course, a package conflict. > > I have tried using "virtual/mymodule" preferred provider but that fails since > it seems to have a recipe "granularity" and we still need virtual/kernel. I > have also messed around with KERNEL_MODULE_PACKAGE_PREFIX and > KERNEL_MODULES_RDEPENDS_BLACKLIST but I get the sense I'm trying to put a > square peg in a round hole. > > I do realize this is an unusual situation and the question "why don't you > just patch the existing driver in the kernel?" is obvious. We do have our > reasons that I won't go into. > > Is there any obvious way we can simply "eclipse" an existing kernel module > with an out-of-tree module? Is there a way I could add a config fragment > that doesn't get validated/sanitized, for example? > > Regards, > > Russell > > Rename your out of tree module to something else. Patch the module that you want to replace so it does not do anything. Enable it and build it. You can also remove the dependency by patching the Kconfig files. Ulf Samuelsson > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] kernel module override
Hello, I have what I would think is an unusual requirement regarding a kernel module and could use some advice. I have a kernel module that has been heavily modified... to the point where we have a separate recipe for it and treat it as an out-of-tree module. This works by not setting the kernel config file to build that module and our meta layer builds and installs the module. No problem... works fine for us. The problem is that we now want to enable another module that relies on the module we build out of tree. The issue is that the check config sees we have not enabled our out of tree module and thus the sanitized config does not contain this module that we want to enable. If we enable the modified module in the config file there is, of course, a package conflict. I have tried using "virtual/mymodule" preferred provider but that fails since it seems to have a recipe "granularity" and we still need virtual/kernel. I have also messed around with KERNEL_MODULE_PACKAGE_PREFIX and KERNEL_MODULES_RDEPENDS_BLACKLIST but I get the sense I'm trying to put a square peg in a round hole. I do realize this is an unusual situation and the question "why don't you just patch the existing driver in the kernel?" is obvious. We do have our reasons that I won't go into. Is there any obvious way we can simply "eclipse" an existing kernel module with an out-of-tree module? Is there a way I could add a config fragment that doesn't get validated/sanitized, for example? Regards, Russell -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
