LKM –SMP symbols and licencing
Welcome to the tutorial guide. The guide will provide a user with advise and guidance on how to SMP symbols and licensing.
The symbol version prefix contains smp if the symbol is defined in or referenced by code that was built for symmetric multiprocessing (SMP) machines. It means that it was built for use on a system that has more than one CPU. A user can choose whether to build in SMP capability or not via the Linux kernel configuration process to wit with the CONFIG_SMP configuration option.
If a user is planning to use symbol versioning then he/she will get unresolved symbols if the base kernel was built with SMP capability and the LKM that he/she is inserting was not, or vice versa.
Please note that there is generally no reason to omit SMP capability from a kernel, even if a user has only one CPU. Just because the capability is there doesn’t mean that a user should have multiple CPUs. However, there are some machines on which the SMP-capable kernel will not boot because it reaches the conclusion that there are zero CPUs
As the copyright owners of some kernel code license their programs to the public to make and use copies so the license may say that you may only call your copy of the program from a program which is similarly licensed to the public.
According to some interpretations, the license says if you make a copy of Shafkat’s LKM, you can’t allow Shahzad’s LKM to call its compression subroutines if Shahzad’s does not supply his source code to the world too. The idea is to encourage Shahzad to open up his source code.
If you would like to support and enforce such a license, the licensor can cause his program to export symbols under a special name that is the real name of the symbol plus the prefix “GPLONLY”. A naive loader of a client LKM would not be able to resolve those symbols. For example: Shafkat’s LKM provides the service ShafkatssService() and declares it to be a GPL symbol. The LKM consequently exports ShafkatsService() under the name GPLONLY_shafkatsService. If Shahzad’s LKM refers to ShafkatsService, the naive loader will not be able to find it, so will fail to load Shahzad’s LKM.
However, a modern version of insmod knows to check for GPLONLY_shafkatsService if it can’t find shafkatsService. But the modern insmod will refuse to do so unless Shahzad’s LKM declares that it is licensed to the public under GPL.
The purpose of this appears to be to prevent anyone from accidentally violating a license (or from credibly claiming that he accidentally violated the license). It is not difficult to circumvent the restriction if you want to. If you see this failure, it is probably because you’re using an old loader (insmode) that doesn’t know about GPLONLY.
The only other cause would be that the LKM author wrote the source code in such a way that it will never load into any Linux kernel, so there would be no point in the author distributing it.
If you followed advise and guidance as provided in this tutorial guide then you would have learnt about SMP symbols and licensing issues.













