Linux Kernel Internals So,as I said earlier,Linux kernel can only be compiled as ELF binary and now we find out the reason(or one of the reasons)for that.The reason related to throwing away initialisation code/data is that Linux provides two macros to be used .init-for initialisation code ●initdata-for data These evaluate to gcc attribute specificators(also known as"gcc magic")as defined in include/linux/init.h attribute (section ("text.init")) attribute (section (".data.init"))) init tendif initdata What this means is that if the code is compiled statically into the kernel (ie moDUle is not defined)then it is placed in the special ELF section".text init"which is declared in the linker map in arch/i386/vmlinux.lds. Otherwise(ie.if it is a module)the macros evaluate to nothing. What happens during boot is that the"init"kernel thread(function init/main.c:init())calls the arch-specific function free_initmem(which frees all the pages between addresses init_begin and init_end. On a typical system(my workstation),this results in freeing about 260K of memory. The functions registered via module_init()are placed in".initcall.init"which is also freed in the static case. The current trend in Linux,when designing a subsystem(not necessarily a module)is to provide init/exit entry points from the early stages of design so that in the future the subsystem in question can be modularized if needed.Example of this is pipefs,see fs/pipe.c.Even if subsystem will never become a module,e.g. bdflush(see fs/buffer.c)it is still nice and tidy to use module_init()macro against its initialisation function. provided it does not matter when exactly is the function called There are two more macros whichwhich work very simila called exit and directly conected to the mdule supprt and therefor illpnenh 1.9 Processing kernel command line Let us recall what happens to the commandline passed to kernel during boot 1.LILO(or BCP)ac cepts the ndline using BIOS keyboard s n in phy emory,as well as a signa at the ture saying t isa valid 1.9 Processing kernel command line 10 So, as I said earlier, Linux kernel can only be compiled as ELF binary and now we find out the reason (or one of the reasons) for that. The reason related to throwing away initialisation code/data is that Linux provides two macros to be used: • __init − for initialisation code • __initdata − for data These evaluate to gcc attribute specificators (also known as "gcc magic") as defined in include/linux/init.h: #ifndef MODULE #define __init __attribute__ ((__section__ (".text.init"))) #define __initdata __attribute__ ((__section__ (".data.init"))) #else #define __init #define __initdata #endif What this means is that if the code is compiled statically into the kernel (i.e. MODULE is not defined) then it is placed in the special ELF section ".text.init" which is declared in the linker map in arch/i386/vmlinux.lds. Otherwise (i.e. if it is a module) the macros evaluate to nothing. What happens during boot is that the "init" kernel thread (function init/main.c:init()) calls the arch−specific function free_initmem() which frees all the pages between addresses __init_begin and __init_end. On a typical system (my workstation), this results in freeing about 260K of memory. The functions registered via module_init() are placed in ".initcall.init" which is also freed in the static case. The current trend in Linux, when designing a subsystem (not necessarily a module) is to provide init/exit entry points from the early stages of design so that in the future the subsystem in question can be modularized if needed. Example of this is pipefs, see fs/pipe.c. Even if subsystem will never become a module, e.g. bdflush (see fs/buffer.c) it is still nice and tidy to use module_init() macro against its initialisation function, provided it does not matter when exactly is the function called. There are two more macros which which work very similar, called __exit and __exitdata but they are more directly connected to the module support and therefore will be explained in a later section. 1.9 Processing kernel command line Let us recall what happens to the commandline passed to kernel during boot. 1. LILO (or BCP) accepts the commandline using BIOS keyboard services and stores it at a well−known location in physical memory, as well as a signature saying that there is a valid commandline there Linux Kernel Internals 1.9 Processing kernel command line 10