Re: __devinit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On 28-11-07 00:42, Mansha Linux wrote:

what is the significance of the __devinit in the init_module()  ?

It's not specific to the module_init() function... It's a pre-processor macro that's defined as:

#  define __devinit
#  define __devinit __init

That is, without CONFIG_HOTPLUG defined, it pre-processes to nothing at all.
When CONFIG_HOTPLUG is defined though, it turns into __init which is again a pre-processor macro:

#define __init __attribute__ ((__section__ (".init.text"))) (*)

this __attribute__ makes GCC emit the function into the specified section (.init.text) of the object file, and the linker later into the specified section of the executable -- the kernel or module in this case.

In this section, functions that are only needed at initialization time are placed so that the entire section can be tossed once the kernel is up and running (in the case of builtin code) or once the module has loaded and initialized in the case of a module. For the kernel proper, you see it discarding this section when it says:

	"Freeing unused kernel memory: xxxk freed"

near the end of the bootup. The advantage ofcourse is that you save xxxk of memory.

Now, the CONFIG_HOTPLUG difference is (was...) intended for hotpluggable hardware. Ofcourse, you can't toss the .init section upon loading the kernel or module if its for hotpluggable hardware, since the code it contains might still be needed later when you _do_ hotplug said hardware. So, with hotplug support enabled in the kernel, the functions just go to the regular kernel text section alongside all other normal functions.

These days CONFIG_HOTPLUG is a bit more generally applicable than just for hotpluggable hardware. Generally, you could for example simulate plugging and unplugging hardware by manipulating sysfs files. This means that you might see the __devinit annotation even on init functions for decidedly un-hotpluggable hardware such as ancient ISA stuff.

Finally, the (*) above is where a "__cold" is in the actual kernel. Don't worry about that one, just (when compiled with a sufficiently recent GCC) turns into another GCC __attribute__ that lets the compiler assume a call to the function is unlikely so that it can optimize code layout better. Not important...


To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at

[Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Networking]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]

Add to Google Powered by Linux