1. 程式人生 > >Linux裝置模型 (1)

Linux裝置模型 (1)

隨著計算機的周邊外設越來越豐富,裝置管理已經成為現代作業系統的一項重要任務,這對於Linux來說也是同樣的情況。每次Linux核心新版本的釋出,都會伴隨著一批裝置驅動進入核心。在Linux核心裡,驅動程式的程式碼量佔有了相當大的比重。下圖是我在網路上搜索到的一幅Linux核心程式碼量的統計圖,對應的核心版本是2.6.29。

我們可以很明顯的看到,在Linux核心中驅動程式的比例已經非常高了。

Linux 2.6核心最初為了應付電源管理的需要,提出了一個裝置模型來管理所有的裝置。在物理上,外設之間是有一種層次關係的,比如把一個U盤插到筆記本上,實際上這個U盤是接在一個USB Hub上,USB Hub又是接在USB 2.0 Host Controller (EHCI)上,最終EHCI又是一個掛在PCI Bus上的裝置。這裡的一個層次關係是:PCI->EHCI->USB Hub->USB Disk。如果作業系統要進入休眠狀態,首先要逐層通知所有的外設進入休眠模式,然後整個系統才可以休眠。因此,需要有一個樹狀的結構可以把所有的外設組織起來。這就是最初建立Linux裝置模型的目的。

當然,Linux裝置模型給我們帶來的便利遠不止如此。既然已經建立了一個組織所有裝置和驅動的樹狀結構,使用者就可以通過這棵樹去遍歷所有的裝置,建立裝置和驅動程式之間的聯絡,根據型別不同也可以對裝置進行歸類,這樣就可以更清晰的去“看”這顆枝繁葉茂的大樹。另外,Linux驅動模型把很多裝置共有的一些操作抽象出來,大大減少了重複造輪子的可能。同時Linux裝置模型提供了一些輔助的機制,比如引用計數,讓開發者可以安全高效的開發驅動程式。達成了以上這些好處之後,我們還得到了一個非常方便的副產品,這就是sysfs----一個虛擬的檔案系統。sysfs給使用者提供了一個從使用者空間去訪問核心裝置的方法,它在Linux裡的路徑是/sys。這個目錄並不是儲存在硬碟上的真實的檔案系統,只有在系統啟動之後才會建起來。

下面這個命令可以用來顯示sysfs的大致結構:

tree /sys

這個命令的資訊量非常大,我就不貼出來了,如果有興趣的話可以看看這裡,或者自己動手實驗一下。

我們來看看第一層目錄結構:

/sys
|-- block
|-- bus
|-- class
|-- dev
|-- devices
|-- firmware
|-- fs
|-- kernel
|-- module
`-- power

這裡有10個子目錄,但並不是說這10個目錄代表了10種完全不同的裝置型別,實際上這些目錄只是給我們提供瞭如何去看整個裝置模型的不同的視角。其實從不同的目錄出發都有可能找到同一個裝置的。那真正的裝置資訊到底放在哪裡呢?看看目錄的名稱就應該能猜到,對,就是devices子目錄,Linux的所有裝置都可以在這個目錄裡找到。這裡是一個大雜燴,雖然五臟俱全但我們卻無從下手。這裡還是以U盤為例,插上U盤之後,在devices目錄裡如何找到這支U盤呢?真得很難辦到。但是如果知道這個U盤在系統裡的裝置檔名(暫且假設為sdb),那就可以從block目錄著手。

透過block目錄,我們很容易就可以找到這個U盤裝置,符號連結device正是指向devices目錄下的位置。

到這裡,我們總結一下/sys目錄下各個子目錄的作用。block目錄是從塊裝置的角度來組織裝置;bus目錄是從系統匯流排這個角度來組織裝置,比如PCI匯流排或者USB匯流排;class目錄把看問題的視角提高到了類別的高度,比如PCI裝置或者USB裝置等;dev目錄的視角是裝置節點;devices目錄在前面提到了,這裡是所有裝置的大本營;firmware目錄包含了一些比較低階的子系統,比如ACPI、EFI等;fs目錄裡看到的是系統支援的所有檔案系統;kernel目錄下包含的是一些核心的配置選項;modules目錄下包含的是所有核心模組的資訊,核心模組實際上和裝置之間是有對應關係的,通過這個目錄順藤摸瓜找到devices或者反過來都是可以做到的;power目錄存放的是系統電源管理的資料,使用者可以通過它來查詢目前的電源狀態,甚至可以直接“命令”系統進入休眠等省電模式。

sysfs正是使用者和核心裝置模型之間的一座橋樑,通過這個橋樑我們可以從核心中讀取資訊,也可以向核心裡寫入資訊。

在Linux裡也可以找到一些圖形化的工具來查詢裝置資訊。比如GNOME下基於HAL的Device Manager:

或者KDE下基於Solid的KInfoCenter:

這些圖形化的工具提供了更加直觀的方式來訪問裝置,但是它們的提供的資訊還不夠全面,而且沒有向核心裝置寫資料的功能。

如果具體到某一型別的裝置,Linux下還有一些專用的工具可以使用。比如面向PCI裝置的pciutils,面向USB裝置的usbutils,以及面向SCSI裝置的lsscsi等。對於Linux開發者來說,有時使用這些專用的工具更加方便。

我們如果要寫程式來訪問sysfs,可以像讀寫普通檔案一樣來操作/sys目錄下的檔案,或者,也可以使用libsysfs。不過需要注意的是,Linux核心社群並不推薦用libsysfs,因為這個API的更新不夠快,趕不上核心的變化。libsysfs已經逐漸背離最初建立它的目標,這個lib帶來的問題似乎比它解決的還要多。當然,如果只是要訪問裝置,一般很少會直接操作sysfs,它太細節太底層了,大部分情況下可以使用更加方便的DeviceKit或者libudev

總結一下,本文主要簡單介紹了Linux裝置模型的基本概念和虛擬檔案系統sysfs。接下來的篇章裡將和大家繼續探討裝置模型在核心空間的一些細節。

相關推薦

Linux裝置模型 (1)

隨著計算機的周邊外設越來越豐富,裝置管理已經成為現代作業系統的一項重要任務,這對於Linux來說也是同樣的情況。每次Linux核心新版本的釋出,都會伴隨著一批裝置驅動進入核心。在Linux核心裡,驅動程式的程式碼量佔有了相當大的比重。下圖是我在網路上搜索到的一幅Linux核心程式碼量的統計圖,對應的核心版本

Linux裝置模型-1-主要概念

0 linux裝置模型出現的背景 隨著計算機的周邊外設越來越豐富,裝置管理已經成為現代作業系統的一項重要任務,這對於Linux來說也是同樣的情況。每次Linux核心新版本的釋出,都會伴隨著一批裝置驅動進入核心。在Linux核心裡,驅動程式的程式碼量佔有了相當大的比重。 為了

Linux裝置模型分析之bus(基於3.10.1核心)

作者:劉昊昱  核心版本:3.10.1 一、bus定義 Linux裝置驅動模型中的bus,即可以是物理匯流排(如PCI、I2C匯流排)的抽象,也可以是出於裝置驅動模型架構需要而定義的虛擬的“platform”匯流排。一個符合Linux裝置驅動模型的device或devi

Linux裝置模型分析之device_driver(基於3.10.1核心)

一、device_driver定義 181/**  182 * struct device_driver - The basic device driver structure  183 * @name:   Name of the device

linux裝置模型十(bus_device_driver總結)

前面九章分別對linux驅動模型中的細節部分進行了分析,本節作為小節,使用一個簡單的例子,分別使用前面分析的內容,實現一個簡單的匯流排,裝置,驅動之間的關係。   實現一條匯流排 #include <linux/device.h> #include <li

linux裝置模型的inode,cdev,kobj_map,char_device_struct

Char Device Driver   相關資料結構: struct cdev {   struct kobject kobj;   struct module *owner;   const struct file_operations *ops;   str

Linux裝置模型之tty驅動架構分析

------------------------------------------ 本文系本站原創,歡迎轉載!轉載請註明出處:http://ericxiao.cublog.cn/------------------------------------------一:前言Tty這個名稱源於電傳打位元組的簡稱。

linux裝置模型之uart驅動架構分析

一:前言 接著前面的終端控制檯分析,接下來分析serial的驅動.在linux中,serial也對應著終端,通常被稱為串列埠終端.在shell上,我們看到的/dev/ttyS*就是串列埠終端所對應的裝置節點. 在分析具體的serial驅動之前.有必要先分析uart

學習《Linux裝置模型淺析之驅動篇》筆記(一)

原文中說了,核心版本為2.6.29;這裡都貼3.15的核心原始碼; 檔案/drivers/rtc/rtc-s3c.c static struct platform_driver s3c_rtc_driver = {         .probe= s3c_rtc_pro

Linux裝置模型之tty&&uart驅動架構分析

五: uart_add_one_port()操作 在前面提到.在對uart裝置檔案過程中.會將操作轉換到對應的port上,這個port跟uart_driver是怎麼關聯起來的呢?這就是uart_add_ont_port()的主要工作了. 顧名思義,這個函式是在uart_driver增加一個port.程式碼如

Linux 檔案系統與裝置檔案系統 (二)—— sysfs 檔案系統與Linux裝置模型

      提到 sysfs 檔案系統 ,必須先需要了解的是Linux裝置模型,什麼是Linux裝置模型呢? 一、Linux 裝置模型 1、裝置模型概述      從2.6版本開始,Linux開發團隊便為核心建立起一個統一的裝置模型。在以前的核心中沒有獨立的資料結構用來讓核

從面向物件的角度看Linux裝置模型

int sysfs_create_file(struct kobject * kobj, const struct attribute * attr) kobj_type中的另外一個重要成員是release()函式指標。當kobject的引用計數為零時該函式指標所指向的函式就會被呼叫,用於釋放相應的系統資源

Linux Device Drivers》第十四章 Linux 裝置模型

簡介 2.6核心的裝置模型提供一個對系統結構的一般性抽象描述,用以支援多種不同的任務 電源管理和系統關機與使用者空間通訊熱插拔裝置裝置型別物件生命週期kobject、kset和子系統 kobject是

linux裝置模型之I2C子系統

=============================== 本文系本站原創,歡迎轉載! 轉載請註明出處:http://blog.csdn.net/gdt_a20 ===============================       I2c子系統將i2c控制器(

Linux 裝置模型基本概念 (一)

1、裝置模型引入 Linux 2.6核心最初為了應付電源管理的需要,提出了一個裝置模型來管理所有的裝置。在物理上,外設之間是有一種層次關係的,比如把一個U盤插到筆記本上,實際上這個U盤是接在一個USB Hub上,USB Hub又是接在USB 2.0 Host Contro

linux裝置模型之spi子系統

=============================== 本文系本站原創,歡迎轉載! 轉載請註明出處:http://www.cnblogs.com/gdt-a20 ===============================       相比於前面介紹的i2c子系統,spi子系

宋寶華《Linux裝置驅動開發詳解》——sysfs檔案系統與linux裝置模型(5.4.2)

以下讀書筆記內容,摘自宋寶華《Linux裝置驅動開發詳解》一書。 1、sysfs檔案系統的簡介 (1)linux2.6以後的核心引進syfs檔案系統,是虛擬檔案系統; (2)產生一個包括所有系統硬體

linux裝置模型二(kobject)

1. 前言 Kobject是Linux裝置模型的基礎,也是裝置模型中最難理解的一部分(可參考Documentation/kobject.txt的表述)。因此有必要先把它分析清楚。 2. 基本概念 由“Linux裝置模型(1)_基本概念”可知,Linux裝置模型的核心

linux裝置模型之mmc,sd子系統

struct mmc_host { 171         struct device           *parent;          172         struct device           class_dev; 173         int                    

linux 裝置模型

2.6核心的裝置模型支援以下特性: 1. 電源管理 2. 與使用者空間通訊 3. 熱插拔裝置 4. 裝置型別管理 5. 物件生命週期 §1. 底層元件kobject, kset, kobj_type, ksubsystem(merge to kset after 2.6.