2.5. Hello World
(part 4): Licensing and Module Documentation
If you're running kernel 2.4 or later, you might have noticed
something like this when you loaded proprietary modules:
# insmod xxxxxx.o
Warning: loading xxxxxx.ko will taint the kernel: no license
See https://www.tux.org/lkml/#export-tainted for information about tainted modules
Module xxxxxx loaded, with warnings
In kernel 2.4 and later, a mechanism was devised to identify
code licensed under the GPL (and friends) so people can be warned
that the code is non open-source. This is accomplished by the
MODULE_LICENSE() macro which is
demonstrated in the next piece of code. By setting the license to
GPL, you can keep the warning from being printed. This license
mechanism is defined and documented in linux/module.h:
* The following license idents are currently accepted as indicating free
* software modules
* "GPL" [GNU Public License v2 or later]
* "GPL v2" [GNU Public License v2]
* "GPL and additional rights" [GNU Public License v2 rights and more]
* "Dual BSD/GPL" [GNU Public License v2
* or BSD license choice]
* "Dual MIT/GPL" [GNU Public License v2
* or MIT license choice]
* "Dual MPL/GPL" [GNU Public License v2
* or Mozilla license choice]
* The following other idents are available
* "Proprietary" [Non free products]
* There are dual licensed components, but when running with Linux it is the
* GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL
* is a GPL combined work.
* This exists for several reasons
* 1. So modinfo can show license info for users wanting to vet their setup
* is free
* 2. So the community can ignore bug reports including proprietary modules
* 3. So vendors can do likewise based on their own policies
Similarly, MODULE_DESCRIPTION() is
used to describe what the module does, MODULE_AUTHOR() declares the module's author, and
MODULE_SUPPORTED_DEVICE() declares what
types of devices the module supports.
These macros are all defined in linux/module.h and aren't used by the kernel
itself. They're simply for documentation and can be viewed by a
tool like objdump. As an exercise
to the reader, try and search fo these macros in linux/drivers to see how module authors use these
macros to document their modules.
I'd recommend to use something like grep -inr
MODULE_AUTHOR * in /usr/src/linux-2.6.x/ . People unfamiliar with
command line tools will probably like some web base solution,
search for sites that offer kernel trees that got indexed with LXR.
(or setup it up on your local machine).
Users of traditional Unix editors, like emacs or vi will also find tag
files useful. They can be generated by make
tags or make TAGS in /usr/src/linux-2.6.x/ . Once you've got such a
tagfile in your kerneltree you can put the cursor on some function
call and use some key combination to directly jump to the
Example 2-6. hello-4.c
* hello-4.c - Demonstrates module documentation.
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_INFO */
#include <linux/init.h> /* Needed for the macros */
#define DRIVER_AUTHOR "Peter Jay Salzman <[email protected]>"
#define DRIVER_DESC "A sample driver"
static int __init init_hello_4(void)
printk(KERN_INFO "Hello, world 4\n");
static void __exit cleanup_hello_4(void)
printk(KERN_INFO "Goodbye, world 4\n");
* You can use strings, like this:
* Get rid of taint message by declaring code as GPL.
* Or with defines, like this:
MODULE_AUTHOR(DRIVER_AUTHOR); /* Who wrote this module? */
MODULE_DESCRIPTION(DRIVER_DESC); /* What does this module do */
* This module uses /dev/testdevice. The MODULE_SUPPORTED_DEVICE macro might
* be used in the future to help automatic configuration of modules, but is
* currently unused other than for documentation purposes.