2.4. Hello World (part 3): The __init and __exit Macros
2007-05-29 20:51
399 查看
This demonstrates a feature of kernel 2.2 and later. Notice the change in the definitions of the init and cleanup functions. The __init macro causes the init function to be discarded and its memory freed once the init function finishes for built-in drivers, but not loadable modules. If you think about when the init function is invoked, this makes perfect sense.
There is also an __initdata which works similarly to __init but for init variables rather than functions.
The __exit macro causes the omission of the function when the module is built into the kernel, and like __exit, has no effect for loadable modules. Again, if you consider when the cleanup function runs, this makes complete sense; built-in drivers don't need a cleanup function, while loadable modules do.
These macros are defined in linux/init.h and serve to free up kernel memory. When you boot your kernel and see something like Freeing unused kernel memory: 236k freed, this is precisely what the kernel is freeing.
Example 2-5. hello-3.c
By the way, you may see the directive "__initfunction()" in drivers written for Linux 2.2 kernels:
This macro served the same purpose as __init, but is now very deprecated in favor of __init. I only mention it because you might see it modern kernels. As of 2.4.18, there are 38 references to __initfunction(), and of 2.4.20, there are 37 references. However, don't use it in your own code.
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.
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 grepping through linux/drivers to see how module authors use these macros to document their modules.
Example 2-6. hello-4.c
There is also an __initdata which works similarly to __init but for init variables rather than functions.
The __exit macro causes the omission of the function when the module is built into the kernel, and like __exit, has no effect for loadable modules. Again, if you consider when the cleanup function runs, this makes complete sense; built-in drivers don't need a cleanup function, while loadable modules do.
These macros are defined in linux/init.h and serve to free up kernel memory. When you boot your kernel and see something like Freeing unused kernel memory: 236k freed, this is precisely what the kernel is freeing.
Example 2-5. hello-3.c
/* hello-3.c - Illustrating the __init, __initdata and __exit macros. */ #include <linux/module.h> /* Needed by all modules */ #include <linux/kernel.h> /* Needed for KERN_ALERT */ #include <linux/init.h> /* Needed for the macros */ static int hello3_data __initdata = 3; static int __init hello_3_init(void) { printk(KERN_ALERT "Hello, world %d/n", hello3_data); return 0; } static void __exit hello_3_exit(void) { printk(KERN_ALERT "Goodbye, world 3/n"); } module_init(hello_3_init); module_exit(hello_3_exit); |
__initfunction(int init_module(void)) { printk(KERN_ALERT "Hi there./n"); return 0; } |
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 the previous example modules:# insmod hello-3.o Warning: loading hello-3.o will taint the kernel: no license See http://www.tux.org/lkml/#export-tainted for information about tainted modules Hello, world 3 Module hello-3 loaded, with warnings |
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 grepping through linux/drivers to see how module authors use these macros to document their modules.
Example 2-6. hello-4.c
/* hello-4.c - Demonstrates module documentation. */ #include <linux/module.h> #include <linux/kernel.h> #include <linux/init.h> #define DRIVER_AUTHOR "Peiter Jay Salzman <p@dirac.org>" #define DRIVER_DESC "A sample driver" int init_hello_3(void); void cleanup_hello_3(void); static int init_hello_4(void) { printk(KERN_ALERT "Hello, world 4/n"); return 0; } static void cleanup_hello_4(void) { printk(KERN_ALERT "Goodbye, world 4/n"); } module_init(init_hello_4); module_exit(cleanup_hello_4); /* You can use strings, like this: */ MODULE_LICENSE("GPL"); // 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. */ MODULE_SUPPORTED_DEVICE("testdevice"); |
相关文章推荐
- Business analysis and SOA part 4 of 6: SOA delivery lifecycle and the top-down approach [by Thomas Erl]
- svn:is not under version control and is not part of the commit, yet its child解决办法
- The Building Blocks-Enterprise Applications Part 3- Differentiation and Innovation
- Configuring and Customizing the Content Query Web Part(转http://blogs.msdn.com/b/ecm/archive/2006/10/
- [Clojure] Data Collection and Data Analysis on the music of www.xiami.com - Part 1
- [Clojure] Data Collection and Data Analysis on the music of www.xiami.com - Part 5
- The Building Blocks-Enterprise Applications Part 2- Information Management and Business Analytics
- The Building Blocks-Enterprise Applications Part 1- Overview and ERP
- The Building Blocks-Enterprise Applications Part 2- Information Management and Business Analytics
- Java theory and practice: Fixing the Java Memory Model, Part 2
- The Anatomy of a COM Server(Chapter 2 of COM and .NET Interoperability) part2
- the part that is good is not original, and the part that is original is not good.
- Home not found. Define system property "openfireHome" or create and add the openfire_init.xml file to the classpath
- 如何打印SharePOint 一部分,而不是整个页面Printing just the web part and not the entire SharePoint page
- The Similarities and Differences Between C# and Java -- Part 1(译)
- Intel-x86-System-Programming-Guide, Part 1,Chapter 2.3 SYSTEM FLAGS AND FIELDS IN THE EFLAGS REGISTER
- The difference between Python __init__ and __new__
- What is the difference between Constructor and ngOnInit?
- symbian add log and get the correct part
- The linux command line--part 3 Common Tasks And Essential Tools