关于__init、__initdata和__exit、__exitdata的学习笔记

本文链接：https://blog.csdn.net/yxfabcdefg/article/details/82907103

__init、__initdata和__exit、__exitdata介绍

定义位于<linux/init.h>:

这些宏定义的作用是告诉编译器将这些函数或者数据放入相应的section中，而在模块加载的阶段，.ko文件中的代码和数据的加载区域是根据section来加载的。

比如：如果函数的定义中带有__init，那么这个函数的所有代码会被放入.init.text的section中。

如果函数的定义中带有__initdata，那么这个函数的所有代码会被放入.init.data的section中。

之所以要使用这个宏定义，其中一个原因是标记为初始化的函数和数据,表明该函数和数据仅在初始化期间使用。在模块装载之后，模块装载就会将初始化函数扔掉。这样可以将该函数占用的内存释放出来。

这种释放根据是否编译进内核是有区别的：

（1）模块编译进内核：所有的初始化数据和函数都是在系统启动的最后阶段，在所有模块都初始化完成以后被内核统一释放的。所有你一般可以在内核启动信息的后面看到：

PHY: 0:01 - Link is Up - 100/Full
VFS: Mounted root (nfs filesystem) on device 0:14.
devtmpfs: mounted
Freeing init memory: 196K
INIT: version 2.86 booting

(__init* 修饰的数据/函数,用于说明它们只在系统开机阶段使用，其占用的空间会在系统完成启动后释放。启动后,它们不再有效)

（2）独立的模块：模块是通过module-init-tool中的insmod的程序利用系统调用来挂载的，而所有的初始化数据和函数都是被这个系统调用所使用的，在模块挂载完成并初始化过后，由系统调用来完成对初始化数据和函数所占空间的释放。

所以对于将内核驱动代码中的函数和数据定义为“初始化”时需要注意：不要将驱动定义的文件方法（如 open、read、write、close）或者驱动在实际工作中需要使用的函数和数据定义为“初始化”属性，因为在驱动初始化后这些东东就已经被释放了，如果使用了就会Oops。

(参考：https://blog.csdn.net/u010373922/article/details/23123785?utm_source=copy)

整体定义在include/linux/init.h中

/* These are for everybody (although not all archs will actually
   discard it in modules) */
#define __init		__section(.init.text) __cold notrace
#define __initdata	__section(.init.data)
#define __initconst	__constsection(.init.rodata)
#define __exitdata	__section(.exit.data)
#define __exit_call	__used __section(.exitcall.exit)

#define __exit __section(.exit.text) __exitused __cold notrace
如果一个函数加了个标记，则它会被放入.exit.text段，该段比较特殊，它被用于模块的退出函数，如果一个模块被编译到了内核映像中而不是以模块的形式编译的则该部分内存可以被链接器忽略，即不把它连接到内核中或者可以在系统启动后将它占用的内存给释放掉；同时如果内核不支持模块卸载，则也可以在链接时或者启动后释放该部分区域所占的内存.

/include/linux/compiler.h

/* Simple shorthand for a section definition 区段定义的简单速记*/
#ifndef __section
# define __section(S) __attribute__ ((__section__(#S)))
#endif

代码整理一下:

/* These are for everybody 这是给每一个的.(尽管不是所有的arch会在模块中抛弃它)
(although not all archs will actually discard it in modules) */
#define __init		__section(.init.text) __cold notrace
#define __initdata	__section(.init.data)
#define __initconst	__constsection(.init.rodata)
#define __exitdata	__section(.exit.data)
#define __exit_call	__used __section(.exitcall.exit)

/*
 * Some architecture have tool chains which do not handle rodata attributes
 * correctly. For those disable special sections for const, so that other
 * architectures can annotate correctly.
 */
#ifdef CONFIG_BROKEN_RODATA
#define __constsection(x)
#else
#define __constsection(x) __section(x)
#endif

/*
 * modpost check for section mismatches during the kernel build.
 * A section mismatch happens when there are references from a
 * code or data section to an init section (both code or data).
 * The init sections are (for most archs) discarded by the kernel
 * when early init has completed so all such references are potential bugs.
 * For exit sections the same issue exists.
 *
 * The following markers are used for the cases where the reference to
 * the *init / *exit section (code or data) is valid and will teach
 * modpost not to issue a warning.  Intended semantics is that a code or
 * data tagged __ref* can reference code or data from init section without
 * producing a warning (of course, no warning does not mean code is
 * correct, so optimally document why the __ref is needed and why it's OK).
 *
 * The markers follow same syntax rules as __init / __initdata.
 */
#define __ref            __section(.ref.text) noinline
#define __refdata        __section(.ref.data)
#define __refconst       __constsection(.ref.rodata)

/* compatibility defines */
#define __init_refok     __ref
#define __initdata_refok __refdata
#define __exit_refok     __ref


#ifdef MODULE
#define __exitused
#else
#define __exitused  __used
#endif

#define __exit          __section(.exit.text) __exitused __cold notrace

/* Used for MEMORY_HOTPLUG */
#define __meminit        __section(.meminit.text) __cold notrace
#define __meminitdata    __section(.meminit.data)
#define __meminitconst   __constsection(.meminit.rodata)
#define __memexit        __section(.memexit.text) __exitused __cold notrace
#define __memexitdata    __section(.memexit.data)
#define __memexitconst   __constsection(.memexit.rodata)

/* For assembly routines 汇编语言 */
#define __HEAD		.section	".head.text","ax"
#define __INIT		.section	".init.text","ax"
#define __FINIT		.previous

#define __INITDATA	.section	".init.data","aw",%progbits
#define __INITRODATA	.section	".init.rodata","a",%progbits
#define __FINITDATA	.previous

#define __MEMINIT        .section	".meminit.text", "ax"
#define __MEMINITDATA    .section	".meminit.data", "aw"
#define __MEMINITRODATA  .section	".meminit.rodata", "a"

/* silence warnings when references are OK */
#define __REF            .section       ".ref.text", "ax"
#define __REFDATA        .section       ".ref.data", "aw"
#define __REFCONST       .section       ".ref.rodata", "a"

大多是和section相关的定义，这个段定义什么作用呢，它是为了告诉链接器应该把这个函数或者数据放置在哪个位置。一般是指放置到内核镜像的哪个位置上。内核相当于一个非常大的可执行程序，它里面包含了好多内容，我们按照分段的原则来存放这些内容。具体段的存放规则是由vmlinux.lds文件定义，它是负责把段信息告诉链接器的，当然我们也要在代码中声明属于哪个段。 
 通常编译器将函数放在.text 节，变量放在.data 或 .bss 节，使用 section 属性，可以让编译器将函数或变量放在指定的节中。那么例如：前面对__init 的定义便表示将它修饰的代码放在.init.text节。内核把段分的非常细致，是因为它会在运行过程中去定位相应的数据和代码，这样将更加方便处理。就像__init 修饰的所有代码都放在.init.text段，它只在启动阶段会被内核调用到，当初始化结束后就会释放这部分内存，以便充分利用内存，这个就是属于内存管理的部分了。