[PROPOSAL] Kernel module binary compatibility with debug features
Bird, Tim <Tim.Bird@...>
; Summary: Kernel module binary compatibility with debug features
; Proposer: Tim Bird, Sony Mobile
== Description ==
Sometimes, the workflow for embedded systems include obtaining kernel modules from
3rd party vendors or other software teams. In certain situations, it can be difficult
to re-compile and re-install these 3rd party modules, even though the kernel on a system
can be re-configured, rebuilt and re-installed.
This feature proposes to isolate the kernel module interface from changes in certain
kernel debug features, so that turning on those feature will not create binary incompatibility
with a newly configured and deployed kernel.
For example, if a kernel is compiled with CONFIG_DEBUG_SPINLOCK, then modules which
use spinlocks may not be able to be supported without being re-compiled with the same
debug option. It is believed that this same restriction applies to the following kernel
It would be nice to be able to enable and disable debug features in the kernel
without changing the kernel's module binary compatibility.
This would involve somehow insulating the kernel from problems when it was
configured with a particular debug feature, but a module does not support
that configuration. This is mainly targetted at things like structure extensions
in the debug case, and having the kernel core detect multiple structure formats
at runtime, and deal with them correctly. It might also involve making sure that
function calls which bypassed the debug infrastructure (such as a spinlock debug
wrappers or a trace wrappers) by the original compiled module continued to work correctly.
== Related work ==
* Module symbol versioning may be related to this.
** See section 6 of: https://www.kernel.org/doc/Documentation/kbuild/modules.txt
== Scope ==
== Contractor Candidates ==
== Comments ==
[[Category:Project proposals 2013]]
On 10/02/2013 03:33:08 PM, Bird, Tim wrote:
; Summary: Kernel module binary compatibility with debug featuresYou're aware that the upstream kernel guys see the lack of binary compatability as a feature, not a bug (punishing binary-only modules), so that not only will this feature probably never go upstream, but you'll quietly piss off multiple senior kernel developers by suggesting it and one of them will "coincidentally" rewrite whatever infrastructure it depends on in an incompatible way within the year?
They haven't got the spare bandwidth to pursue much legal action in court, but EXPORT_SYMBOL_GPL() is just the tip of the iceberg...