簡介

container_of(ptr, type, member)是內核中的經典函式之一，該函式的作用是：根據結構體中一個成員的地址，找到結構體的地址，這個函式是內核實作面向物件的基礎設施，且最近在學習中經常見到這個函式，于是筆者在內核中查看了該函式的實作，故在此記錄，本文原本是為了展示container_of的實作，但寫著寫著，發現有些內建函式與GNU C拓展的使用，所以就順便查了資料，也一并記錄于此，寫得比較亂，請大家諒解，

基礎知識

結構體在記憶體中的分布，是按照成員的順序分配記憶體，同時保持記憶體對齊的要求

實作分析

原始碼

該函式在5.17.5中的實作在include/linux/container_of.h中

5.16之前，這個宏都被放在include/linux/kernel.h中

原始碼如下：

/**
 * container_of - cast a member of a structure out to the containing structure
 * @ptr:	the pointer to the member.
 * @type:	the type of the container struct this is embedded in.
 * @member:	the name of the member within the struct.
 *
 */
#define container_of(ptr, type, member) ({				\
	void *__mptr = (void *)(ptr);					\
	static_assert(__same_type(*(ptr), ((type *)0)->member) ||	\
		      __same_type(*(ptr), void),			\
		      "pointer type mismatch in container_of()");	\
	((type *)(__mptr - offsetof(type, member))); })

引數

• ptr：成員指標
• type：結構體型別
• mem：成員在結構體里的名稱

第一行：賦值

將傳入的成員變數的地址，轉換為void *型別，并賦給另一個值，這個操作筆者沒有理解，所以找了以前版本的原始碼來進行分析，在2.6.23里，他的實作是這樣的：

#define container_of(ptr, type, member) ({			\
	const typeof( ((type *)0)->member ) *__mptr = (ptr);	\
	(type *)( (char *)__mptr - offsetof(type,member) );})

這個版本中，第一行的作用其實相當于賦值+檢查，考慮如果傳進來的指標型別和member不一致，編譯器會報warning，
在使用查看了相關的log之后，發現這個宏是在提交c7acec713d14c被改變的，改變的原因是：如果結構體內引入了一個非const陣列成員，那么這個指標就會產生變數賦值給常量的問題，這會在gcc-4.9中產生一個warning: initialization from incompatible pointer type，這一筆改動抽離出了型別檢查，但__mptr仍留在原處，筆者實在不清楚這個操作的深意，又或許只是歷史遺留問題？

第二行：檢查

static_assert(__same_type(*(ptr), ((type *)0)->member) ||	\
            __same_type(*(ptr), void),			\
            "pointer type mismatch in container_of()");	\

這個地方在5.16后修改成static_assert，之前使用的是BUILD_BUG_ON()這個宏，他和static_assert被定義在同一個檔案里，感興趣的朋友們可以去看一看相關實作，根據commit message顯示，使用static_assert可以給出更加直接的錯誤提示，并且在理論上可以提升一點點的build速度（commit message里寫了a tiny bit faster）

一個斷言，用于檢查ptr和member的型別一致性，這個斷言函式static_assert()我們先放在一邊，來分析一下這個斷言的第一個引數：內部使用了__same_type()這個宏，來看看這個宏的實作：

/* Are two types/vars the same type (ignoring qualifiers)? */
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))

這個宏使用了兩個函式：__builtin_types_compatible_p()和typeof()，

typeof()想必大家都比較熟悉了，它是一個GNU C的拓展，作用是獲取變數的型別，檔案地址：https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
__builtin_types_compatible_p(type1, type2)是一個GNU C的內建函式，用于比較兩個型別是否相等，若相等則回傳1，不等則回傳0，需要注意的是，這個函式的引數并不是運算式，而是變數型別，所以需要使用typeof()先取得變數型別后再傳入，檔案地址：https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

最后我們再來看一看static_assert()，這個函式的實作位于include/linux/build_log.h，原始碼如下：

#define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
#define __static_assert(expr, msg, ...) _Static_assert(expr, msg)

關于C宏定義中#符號的用法，可以總結為以下兩點：

1. 前加##，轉換為合法識別符號

#define to_symbol(x)  T_##x

// 下面這句等效于 int T_1 = 10;
int to_symbol(1) = 10;

2. 前加#，轉換為字串

#define to_string(x) #x

// 下面這句等效于 "a+b+c"
to_string(a+b+c);

那##__VA_ARGS__又是什么呢？它的功能有兩個：

1. 如果可變引數串列為空，使編譯器忽略它以及它前面的逗號
2. 如果可變引數串列不為空，編譯器將其替換為可變引數串列

接著再來看一看_Static_assert(expr, msg, ...)，這是一個C11特性，用來在編譯時測驗expr的正確性，如果正確則什么都不會發生，如果錯誤，則列印指定資訊msg，檔案地址：https://www.gnu.org/software/gnulib/manual/html_node/assert_002eh.html

綜上所述，第二行的作用就是：判斷傳入的ptr和member（或者void）是否為同一型別，若否，則列印"pointer type mismatch in container_of()"

第三行：尋址

這一行真正用于獲取結構體的地址，

((type *)(__mptr - offsetof(type, member)));

看上去很簡單！就是用傳進來的成員變數地址值減去它在結構體里的偏移值嘛！
邏輯上來講確實很簡單，但是如何實作呢？如何在不同的對齊下讓這個函式均能成功運行呢？讓我們帶著這個疑問走進offsetof()這個宏：

// At include/linux/stddef.h
#define offsetof(TYPE, MEMBER)	((size_t)&((TYPE *)0)->MEMBER)

也很簡單對吧？把0地址轉換成結構體型別指標，然后利用這個特殊的結構體指標獲取member，然后再對member取地址，得到的這個值就是member相對于0地址的偏移值，這個偏移值不就是member相對于結構體首地址的偏移值嘛!
看到這里，如果你和筆者一樣是內核初學者，你可能會和筆者一樣驚訝：0地址還能這么用？！！筆者也是在發出了這樣的感嘆之后，才決定記錄下這篇隨筆，
offsetof這個宏還有另一個實作，即呼叫GNU C的內建函式__builtin_offsetof，本質上和上面的定義是一致的，

總結

這個宏包括了三步：賦值、檢查、尋址，筆者分析了2.6.23中的賦值操作目的與最新的5.17.5中的檢查和尋址操作，
在最后希望詢問看到這篇文章的朋友們一個問題：為什么最新的版本還需要賦值給__mptr，能否在第三行中直接使用(void *)ptr代替__mptr？

原創文章，如有錯漏，敬請補充指正，如對于文章風格有建議，請在評論區直接提出，感謝，

標籤：其他

上一篇：CentOS7 安裝MYSQL5.7

下一篇：windows11電腦連接藍牙耳機的 Hands-free AG Audio和stereo模式