Linux設備樹詳解
時間：2018-08-16 來源：未知
ARM Linux社區為什么要引入設備樹
Linux之父Linus Torvalds閑來無事，在翻看ARM Linux代碼的時候，有一天終于忍不住了。他在2011年3月17日的ARM Linux郵件列表中說道：“This whole ARM thing is a f*cking pain in the ass”。這句話迫使ARM Linux社區引入了設備樹。
Linus Torvalds為什么會發飆呢?而ARM Linux社區的牛人為什么又乖乖地聽話了?你得首先理解Linux設備驅動框架中一個非常好的設計：設備信息和驅動分離。
為了什么說明設備信息和驅動分離的概念，先來看一個簡單的模擬代碼實例：
【例-1】實現一個代碼，把要使用的信息簡單寫死在代碼中：
int add() /*模擬驅動代碼*/
{
return 3+5; /*模擬設備信息*/
}
優點：簡單
缺點：一旦加數和被加數發生變化就得改代碼
改進設計如下：
【例-2】實現一個代碼，把要使用的信息和操作代碼分離開來：
struct dev{
int id;
int x;
int y;
}; /*模擬設備信息結構*/
strcut drv{
int id;
int (*add)(struct dev *info);
}; /*模擬驅動結構*/
int add(struct dev *info) /*模擬驅動代碼*/
{
return info->x + info->y; /*模擬設備信息-通過參數傳遞進來*/
}
struct drv drv = {
.id = 1,
.add = add,
};
/*模擬設備信息*/
struct dev dev = {
.id = 1,
.x = 3,
.y = 5,
};
/*模擬總線初始化匹配設備信息和驅動代碼*/
int bus()
{
if(dev.id == drv.id){
return drv.add(&dev);
}
...
}
優點：不管加數和被加數怎么變化，不需要修改代碼，僅需要修改信息
缺點：結構比較復雜
那這個設備信息和驅動分離的設計跟驅動有什么關系呢?熟悉硬件編程的同學都知道，硬件一般的構成可以使用下圖簡單表述：
操作外設的驅動代碼邏輯，只要硬件是一樣的，就不會變化。但是外設掛到不同的主機上，可能會存在I/O地址的變化，如果有中斷也是一樣的，中斷號也可能不同。這些I/O地址和中斷號就是設備信息，使用這些信息來操作控制硬件的代碼就是驅動。
如果采用【例-1】的設計方式，那么同一個硬件外設接到不同的主機，或是換了地址線/中斷線，設備信息就變化了，得去修改驅動。但是采用【例-2】的方式進行設計，問題就迎刃而解：不管同樣的外設硬件接到哪里或是那個平臺，其驅動代碼邏輯并不需要改動，而僅僅需要改變下設備信息，主要的就是I/O地址和中斷號。
說了這么半天，跟引入設備樹有什么關系呢?華清教學使用的開發板(A8/A9)都使用DM9000網卡芯片。DM9000驅動是開源的，在主線內核源碼中就有。我們每次基于A8/A9板子移植的時候，DM9000驅動并沒有修改過，僅僅是選配了下，主要的工作是在板級文件中添加了設備信息。DM9000驅動使用的是platform框架，所以添加了一份DM9000網卡芯片的platform_device信息。問題來了，如果使用C代碼的形式來描述設備信息，則在內核源碼中，將會有多份DM9000的platform_device設備信息，造成了內核代碼冗余。
解決這個問題的辦法就是引入設備樹，改造【例-2】來說明設備樹的作用。
【例-3】實現一個代碼，不僅把要使用的信息和操作代碼分離開來，而且信息不是C代碼編寫的，而是文本配置文件保存的：
struct dev{
int id;
int x;
int y;
}; /*模擬設備信息結構*/
strcut drv{
int id;
int (*add)(struct dev *info);
}; /*模擬驅動結構*/
int add(struct dev *info) /*模擬驅動代碼*/
{
return info->x + info->y; /*模擬設備信息-通過參數傳遞進來*/
}
struct drv drv = {
.id = 1,
.add = add,
};
/*模擬設備樹-一個特殊的配置文件，xxx.dtbs的文本文件*/
/{
......
Dm9000{
x = 3;
y = 5;
};
......
};
/*模擬總線初始化匹配設備信息和驅動代碼*/
int bus()
{
/*模擬設備樹初始化處理*/
讀文件(xxx.dtbs);
解析文件內容(根據設備樹的規則來解析);
生成struct dev設備信息;
if(dev.id == drv.id){
return drv.add(&dev);
}
...
}
如果像【例-3】這樣，就可以解決大量設備信息的代碼冗余問題。
推而廣之，系統的軟硬件信息都可以使用設備樹來描述。這樣的話，ARM Linux社區就不會因為支持板子和驅動越來越多造成內核源碼中出現很多冗余代碼(主要是板級文件)，僅僅需要移植者，把系統的軟硬件信息通過設備樹提供出來，選配一下內核代碼，就可以了。
