linux裝置驅動模型的前提就是裝置以及驅動適配了才可以載入驅動probe工作，一開始linux的硬體裝置資訊都是通過rch/arm/mach-***檔案描述成許多多的裝置資訊的，然後在系統載入起來的時候裝置與驅動匹配成功開始載入驅動程式呢，但是這些**包含許多硬體板級資訊細節，**多而且冗餘，不好搞。所以提出裝置樹裝置配置方式，說那麼多就是linux覺得以前那套裝置資訊配置方式不好，提出了一種新的硬體裝置描述方式。而這種就是裝置樹。
１．裝置樹的組成以及設計概念。
裝置樹組成通過節點以及屬性組成，從最開始/根節點開始，節點包含屬性，節點也可以包含節點，這樣不斷鋪展開來成樹型似的，所以叫裝置樹。節點可以說是像我們的目錄一樣，從最開始的根目錄開始，目錄可以包含檔案也可以包含目錄，不斷展開成目錄樹，目錄下面有可以包含檔案，而我們的屬性對於節點來說，就像是目錄下的檔案。
總結:２．裝置樹字尾檔名
.dtsi:代表共有的裝置屬性寫成乙個dtsi裝置樹檔案字尾，可以通過像c語言的include "***.dtsi"一樣把該檔案的裝置屬性包含進來。
.dts:裝置樹檔名字尾，裡面描述各種裝置資訊，並且通過節點形式形成。
dtc:裝置樹解析編譯的工具檔案，在scripts/dtc/目錄下，可以這樣理解，ｃ語言是一門語言，定義c語言的編寫規範，但是還是需要有編譯器等工具才能將其解析成機器識別的二進位制檔案，這樣才可以執行。同樣，裝置樹是一種硬體裝置資訊描述資訊的規範，也有一定的語法規則，因此同樣需要工具解析編譯才能編譯成核心識別的檔案才行。而dtc檔案便是這樣的工具。
.dtb:裝置解析編譯後的二進位制檔案字尾名，同樣ｃ語言進過編譯後會形成***.o的二進位制檔案，而裝置樹也是通過dtc編譯成二進位制的.dtb字尾的檔案。
總結:
裝置樹包含dtsi,dts,dtc以及dtb檔案，這樣檔案編寫或者編譯過程生成真的很像一門語言的規範設計，但是其比一門語言的規範簡單的多很多，只能說設計概念很像。
1.節點組成格式:
lable:name[@unit_address]
;
＠unit_address:裝置位址
uart0: serial@f8036000
;
(1)引用lable來包含該節點
```powershell
syscon: syscon@f8000000
;pcie: pcie@f8050000
;
/*的方式就是在原來的基礎上在即擴充套件了該lable節點的資訊。*/
&lable
;
節點｛｝裡面的資訊代表者節點屬性，每個屬性核心都有對應介面解析以及獲取，至於原理是如何我們後續可以再分析，這裡我們只需要了解屬性的編寫規範以及代表的意思便可。
lable:name[@unit_address]
4.裝置樹常用介面
對 React Context 的理解以及應用
很多優秀的react元件都通過context來完成自己的功能 在react元件開發中，如果用好context，可以讓你的元件變得強大，而且靈活。簡單說就是，當你不想在元件樹中通過逐層傳遞props或者state的方式來傳遞資料時，可以使用context來實現跨層級的元件資料傳遞。使用props或者s...
MVC以及JDBC的理解和應用
c即controller控制器主要負責人機互動，呼叫業務邏輯。m即model模型進行業務邏輯判斷，對資料庫進行增刪查改。v即view檢視負責將處理結果直觀的顯示給使用者。三者間的相互關係如下 book類 public class book public void setid int id publi...
許可權設計 以及 樹的儲存
平時看到各位園子的朋友真的很厲害，設計了很多關於許可權管理的東西，很羨慕，但同時也覺得在一些小型專案上，那樣的設計是否有點設計過度呢 其實這也說不清，可能是自己資歷尚淺，還沒看明白各位高人的設計 自己也寫了個，帖出來請教下園子的各位朋友 用pd 弄了個圖，這裡想說明的是關於部門表和模組表的 索引 字...