container_of()宏

在學習Linux驅動的過程當中，遇到一個宏叫作container_of。該宏定義在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) ({                      \ 
const typeof( ((type *)0)->member ) *__mptr = (ptr);    \ 
(type *)( (char *)__mptr - offsetof(type,member) );})

它的做用顯而易見，那就是 根據一個結構體變量中的一個域成員變量的指針來獲取指向整個結構體變量的指針 。好比，有一個結構體變量，其定義以下：

struct demo_struct { 
           type1 member1; 
           type2 member2; 
           type3 member3; 
           type4 member4; 
};      
struct demo_struct demo;

同時，在另外一個地方，得到了變量demo中的某一個域成員變量的指針，好比：

type3  *memp = get_member_pointer_from_somewhere();

此時，若是須要獲取指向整個結構體變量的指針，而不單單只是其某一個域成員變量的指針，咱們就能夠這麼作：

struct demo_struct *demop = container_of(memp, struct demo_struct, member3);

這樣，咱們就經過一個結構體變量的一個域成員變量的指針得到了整個結構體變量的指針。

下面說一說我對於這個container_of的實現的理解：
首先，咱們將container_of(memp, struct demo_struct, type3)根據宏的定義進行展開以下：

struct demo_struct *demop = ({                      \ 
         const typeof( ((struct demo_struct *)0)->member3 ) *__mptr = (memp);    \ 
         (struct demo_struct *)( (char *)__mptr - offsetof(struct demo_struct, member3) );})

其 中，typeof是GNU C對標準C的擴展， 它的做用是根據變量獲取變量的類型。所以，上述代碼中的第2行的做用是首先使用typeof獲取結構體域變量member3的類型爲 type3，而後定義了一個type3指針類型的臨時變量__mptr，並將實際結構體變量中的域變量的指針memp的值賦給臨時變量__mptr。

(char *)__mptr轉換爲字節型指針。(char *)__mptr - offsetof(type,member) )用來求出結構體起始地址（爲char *型指針），而後(type *)( (char *)__mptr - offsetof(type,member) )在(type *)做用下進行將字節型的結構體起始指針轉換爲type *型的結構體起始指針。

假設結構體變量demo在實際內存中的位置以下圖所示：
     demo
 +-------------+ 0xA000
 |   member1   |
 +-------------+ 0xA004
 |   member2   |
 +-------------+ 0xA010
 |   member3   |
 +-------------+ 0xA018
 |   member4   |
 +-------------+

則，在執行了上述代碼的第2行以後__mptr的值即爲0xA010。

再看上述代碼的第3行，其中須要說明的是offsetof，它定義在include/linux/stddef.h中，其定義以下：

#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)

先分析一下這個宏的運行機理（ 一共4步）：

1.  ( (TYPE *)0 ) 將零轉型爲TYPE類型指針; 
2.  ((TYPE *)0)->MEMBER 訪問結構中的數據成員; 
3.  &( ( (TYPE *)0 )->MEMBER )取出數據成員的地址; 
4. (size_t)(&(((TYPE*)0)->MEMBER))結果轉換類型。巧妙之處在於將0轉換成(TYPE*)，結構之內存空間首地址0做爲起始地址，則成員地址天然爲偏移地址；

一樣，咱們將上述的offsetof調用展開，即爲：

(struct demo_struct *)( (char *)__mptr - ((size_t) &((struct demo_struct *)0)->member3) );

可見，offsetof的實現原理如上所述， 就是取結構體中的域成員相對於地址0的偏移地址，也就是域成員變量相對於結構體變量首地址的偏移。

因 此，offsetof(struct demo_struct, member3)調用返回的值就是member3相對於demo變量的偏移。結合上述給出的變量地址分佈圖可知，offsetof(struct demo_struct, member3)將返回0x10。

因而，由上述分析可知，此時，__mptr==0xA010，offsetof(struct demo_struct, member3)==0x10。
所以， (char *)__mptr - ((size_t) &((struct demo_struct *)0)->member3) == 0xA010 - 0x10 == 0xA000，也就是結構體變量demo的首地址（如上圖所示）。

這就是從結構體某成員變量指針來求出該結構體的首指針。指針類型從結構體某成員變量類型轉換爲該結構體類型。

由此，container_of實現了根據一個結構體變量中的一個域成員變量的指針來獲取指向整個結構體變量的指針的功能。

以上內容載自網絡，這篇文章分析的很透徹，順便說一下，宋寶華的《linux設備驅動開發詳解》P132 最後一行當中對該宏的參數解釋是錯誤的！固然了，暇不掩瑜！

如下是我本身的一些理解：

首先，我定義了一個字符設備結構體

struct globalmem_dev
{
    struct cdev   my_cdev;            //字符設備之基礎結構體 
    unsigned char mem[GLOBALMEM_SIZE];    
    struct semaphore sem;/
};

接下來我實例化了一個該設備的指針對象

struct globalmem_dev *pdev;

後來在open函數中我是這麼來用的

//關於filp的產生和消亡參見《驅動詳解》P92
int globalmem_open(struct inode *inode, struct file *filp)
{                                   
    struct globalmem_dev *pdev;    
    printk("\nFunction globalmem_open Invoked\n");    
    pdev = container_of(inode->i_cdev,  struct   globalmem_dev,  my_cdev);
    filp->private_data = pdev;    
    if(down_trylock(&pdev->sem))//得到信號量
        return -EBUSY;     
    return 0;
}

對以上用法的說明： 參數3是參數2這個結構體的一個成員的名字！而不是類型名！參數1是一個指針，它指向參數3這個成員 inode 中的i_cdev字段是一個指針，當咱們成功insmod了一個設備驅動的時候，咱們會經過mknod建立一個設備文件節點並和具體設備（驅動）想關聯， 這個設備文件節點所對應的就是struct inode結構體的一個實例，這個結構體有一個字段i_cdev，是個struct   cdev類型的指針，它會指向設備結構體的my_cdev字段。至此你已經有了一個指向某個 globalmem_dev的my_cdev字段的一個指針（在調用open前pdev的內存分配假定已經完成）由此container_of能夠幫你計算出指向該設備結構體的指針。 當一個設備驅動對應多個設備（子設備）時，你就知道 container_of發揮的做用了！當你針對每個設備調用open時，由於每一個設備對應的設備文件節點不同，那麼根據該節點的i_cdev字段所計算的設備結構體指針也不同，你就能夠找到特定節點所對應的設備結構體！而不至於對不一樣的子設備編寫大同小異的各自的設備驅動