Re: toolchain requirements for external kernel modules
On 2/19/19 10:47 AM, Dulaney wrote: On Gearr 18, 2019 aig 12:26:04f -0800, sgrìobh Laura Abbott: Yes, that was the case I was concerned about with gcc being updated. I guess the case would be where the kernel gets built with a different gcc that isn't yet on a local system. Doing a batched bodhi update could fix this for stable releases but we don't have that on rawhide. Requiring the sync also seems like a pain to deal with. Laura So, just out of curiosity, why can't these be in their own rpm(s) that get updated every time gcc does? If I'm reading you correctly, the gcc modules are dependent on gcc, not the kernel features on specific versions of the gcc modules. No, these plugins are tied to the kernel itself and can be updated with each kernel version. They need to exist in the kernel spec file at kernel build time. They aren't dependent on the gcc version per se but they need to get rebuilt each time there is a new gcc. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: toolchain requirements for external kernel modules
On Gearr 18, 2019 aig 12:26:04f -0800, sgrìobh Laura Abbott: > Yes, that was the case I was concerned about with gcc being updated. > I guess the case would be where the kernel gets built with a different > gcc that isn't yet on a local system. Doing a batched bodhi update > could fix this for stable releases but we don't have that on rawhide. > Requiring the sync also seems like a pain to deal with. > > Laura So, just out of curiosity, why can't these be in their own rpm(s) that get updated every time gcc does? If I'm reading you correctly, the gcc modules are dependent on gcc, not the kernel features on specific versions of the gcc modules. -- Tapadh leabh, Dulaney. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: toolchain requirements for external kernel modules
On 2/15/19 3:47 AM, Florian Weimer wrote: * Laura Abbott: I've been experimenting with enabling CONFIG_GCC_PLUGINS in the kernel since I've heard some people express interest in stackleak (I'm interested as well). a gcc plugin gets built as an .so file for use during compilation. This means we need to package this .so file as part of kernel-devel for building external modules. This is easy to do but it also now introduces a tighter restriction on the toolchain used for building modules since gcc will refuse to load a plugin and fail to build the module if the versions don't match. Arguably, there's always been a requirement to use the same toolchain version but there may have been some flexibility for forcing it. Can anyone see major problems with requiring the same toolchain version for building external modules as the kernel? If those kernel modules happen to build userspace components as well (and use the right build flags), then they have such a toolchain dependency already, indirectly through the annobin plugin. The main caveat I see is that it is tricky to handle the version constraints correctly (both in the plugin and at the RPM level). For a long time, the annobin constraints were too tight. Most modules are probably not going to be compiling userspace components so I'm not too concerned there. Thanks for the pointer to annobin though, I hadn't thought about how to actually specify the requirement in the rpm file. I'm not sure if this example convinces me I should do gcc plugins or it's not worth the hassle. Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: toolchain requirements for external kernel modules
On 2/14/19 4:19 PM, stan wrote: On Thu, 14 Feb 2019 15:09:04 -0800 Laura Abbott wrote: Can anyone see major problems with requiring the same toolchain version for building external modules as the kernel? If gcc is updated between Fedora kernel versions and someone wants to build a module, it would build but be unuseable? If that is true, then gcc updates should just be released at the same time as a kernel built with them to finesse the issue. I suspect that this would be a rare issue in practice. Oops, I forgot about rpmfusion, where they do build modules, and akmod which builds modules automatically when a new kernel is released. That would make it more likely to occur, I think. Yes, that was the case I was concerned about with gcc being updated. I guess the case would be where the kernel gets built with a different gcc that isn't yet on a local system. Doing a batched bodhi update could fix this for stable releases but we don't have that on rawhide. Requiring the sync also seems like a pain to deal with. Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Re: toolchain requirements for external kernel modules
On Thu, 14 Feb 2019 15:09:04 -0800 Laura Abbott wrote: > Can anyone see major problems with requiring the same toolchain > version for building external modules as the kernel? If gcc is updated between Fedora kernel versions and someone wants to build a module, it would build but be unuseable? If that is true, then gcc updates should just be released at the same time as a kernel built with them to finesse the issue. I suspect that this would be a rare issue in practice. Oops, I forgot about rpmfusion, where they do build modules, and akmod which builds modules automatically when a new kernel is released. That would make it more likely to occur, I think. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
