linux2.6核心引入sysfs檔案系統，sysfs可以看成與proc,devfs和devpty同類別的檔案系統，該檔案系統是虛擬的檔案系統，可以更方便對系統裝置進行管理。它可以產生一個包含所有系統硬體層次檢視，與提供程序和狀態資訊的proc檔案系統十分類似。
sysfs把連線在系統上的裝置和匯流排組織成為一個分級的檔案，它們可以由使用者空間存取，向用戶空間匯出核心的資料結構以及它們的屬性。sysfs的一個目的就是展示裝置驅動模型中各元件的層次關係，其頂級目錄包括block,bus,drivers,class,power和firmware等.

sysfs 與 /sys

    sysfs 檔案系統總是被掛載在 /sys 掛載點上。雖然在較早期的2.6核心系統上並沒有規定 sysfs 的標準掛載位置，可以把 sysfs 掛載在任何位置，但較近的2.6核心修正了這一規則，要求 sysfs 總是掛載在 /sys 目錄上；針對以前的 sysfs 掛載位置不固定或沒有標準被掛載，有些程式從 /proc/mounts 中解析出 sysfs 是否被掛載以及具體的掛載點，這個步驟現在已經不需要了。請參考附錄給出的 sysfs-rules.txt 檔案連結。

    sysfs 與 proc

    sysfs 與 proc 相比有很多優點，最重要的莫過於設計上的清晰。一個 proc 虛擬檔案可能有內部格式，如 /proc/scsi/scsi ，它是可讀可寫的，(其檔案許可權被錯誤地標記為了 0444 ！，這是核心的一個BUG)，並且讀寫格式不一樣，代表不同的操作，應用程式中讀到了這個檔案的內容一般還需要進行字串解析，而在寫入時需要先用字串格式化按指定的格式寫入字串進行操作；相比而言， sysfs 的設計原則是一個屬性檔案只做一件事情， sysfs 屬性檔案一般只有一個值，直接讀取或寫入。整個 /proc/scsi 目錄在2.6核心中已被標記為過時(LEGACY)，它的功能已經被相應的 /sys 屬性檔案所完全取代。新設計的核心機制應該儘量使用 sysfs 機制，而將 proc 保留給純淨的“程序檔案系統”。

表 1. /sys 下的目錄結構

sysfs 是在這個 Linux 統一裝置模型的開發過程中的一項副產品(見 參考資料 中 Greg K. Hartman 寫作的 LinuxJournal 文章)。為了將這些有層次結構的裝置以使用者程式可見的方式表達出來，人們很自然想到了利用檔案系統的目錄樹結構（這是以 UNIX 方式思考問題的基礎，一切都是檔案！）在這個模型中，有幾種基本型別，它們的對應關係見 表 2. Linux 統一裝置模型的基本結構 ：

    表 2. Linux 統一裝置模型的基本結構

從核心在實現它們時所使用的資料結構來說， Linux 統一裝置模型又是以兩種基本資料結構進行樹型和連結串列型結構組織的：

    kobject: 在 Linux 裝置模型中最基本的物件，它的功能是提供引用計數和維持父子(parent)結構、平級(sibling)目錄關係，上面的 device, device_driver 等各物件都是以 kobject 基礎功能之上實現的；

struct kobject {
        const char              *name;
        struct list_head        entry;
        struct kobject          *parent;
        struct kset             *kset;
        struct kobj_type        *ktype;
        struct sysfs_dirent     *sd;
        struct kref             kref;
        unsigned int state_initialized:1;
	unsigned int state_in_sysfs:1;
        unsigned int state_add_uevent_sent:1;
        unsigned int state_remove_uevent_sent:1;
}; 

    其中 struct kref 內含一個 atomic_t 型別用於引用計數， parent 是單個指向父節點的指標， entry 用於父 kset 以連結串列頭結構將 kobject 結構維護成雙向連結串列；

    kset: 它用來對同類型物件提供一個包裝集合，在核心資料結構上它也是由內嵌一個 kboject 實現，因而它同時也是一個 kobject (面向物件 OOP 概念中的繼承關係) ，具有 kobject 的全部功能；

struct kset {
        struct list_head list;
        spinlock_t list_lock;
        struct kobject kobj;
        struct kset_uevent_ops *uevent_ops;
}; 

    其中的 struct list_head list 用於將集合中的 kobject 按 struct list_head entry 維護成雙向連結串列；

    涉及到檔案系統實現來說， sysfs 是一種基於 ramfs 實現的記憶體檔案系統，與其它同樣以 ramfs 實現的記憶體檔案系統(configfs,debugfs,tmpfs,...)類似， sysfs 也是直接以 VFS 中的 struct inode 和 struct dentry 等 VFS 層次的結構體直接實現檔案系統中的各種物件；同時在每個檔案系統的私有資料 (如 dentry->d_fsdata 等位置) 上，使用了稱為 struct sysfs_dirent 的結構用於表示 /sys 中的每一個目錄項。

struct sysfs_dirent {
        atomic_t                s_count;
        atomic_t                s_active;
        struct sysfs_dirent     *s_parent;
        struct sysfs_dirent     *s_sibling;
        const char              *s_name;
    union {
            struct sysfs_elem_dir           s_dir;
            struct sysfs_elem_symlink       s_symlink;
            struct sysfs_elem_attr          s_attr;
            struct sysfs_elem_bin_attr      s_bin_attr;
    };

    unsigned int            s_flags;
    ino_t                   s_ino;
    umode_t                 s_mode;
    struct iattr            *s_iattr;

};

    在上面的 kobject 物件中可以看到有向 sysfs_dirent 的指標，因此在sysfs中是用同一種 struct sysfs_dirent 來統一裝置模型中的 kset/kobject/attr/attr_group.

    具體在資料結構成員上， sysfs_dirent 上有一個 union 共用體包含四種不同的結構，分別是目錄、符號連結檔案、屬性檔案、二進位制屬性檔案；其中目錄型別可以對應 kobject，在相應的 s_dir 中也有對 kobject 的指標，因此在核心資料結構， kobject 與 sysfs_dirent 是互相引用的；

    有了這些概念，再來回頭看 圖 1. sysfs 目錄層次圖 所表達的 /sys 目錄結構就是非常清晰明瞭:

    在 /sys 根目錄之下的都是 kset，它們組織了 /sys 的頂層目錄檢視；
    在部分 kset 下有二級或更深層次的 kset；
    每個 kset 目錄下再包含著一個或多個 kobject，這表示一個集合所包含的 kobject 結構體；
    在 kobject 下有屬性(attrs)檔案和屬性組(attr_group)，屬性組就是組織屬性的一個目錄，它們一起向用戶層提供了表示和操作這個 kobject 的屬性特徵的介面；
    在 kobject 下還有一些符號連結檔案，指向其它的 kobject，這些符號連結檔案用於組織上面所說的 device, driver, bus_type, class, module 之間的關係；
    不同型別如裝置型別的、裝置驅動型別的 kobject 都有不同的屬性，不同驅動程式支援的 sysfs 介面也有不同的屬性檔案；而相同型別的裝置上有很多相同的屬性檔案；
    注意，此表內容是按照最新開發中的 2.6.28 核心的更新組織的，在附錄資源如 LDD3 等位置中有提到 sysfs 中曾有一種管理物件稱為 subsys (子系統物件)，在最新的核心中經過重構認為它是不需要的，它的功能完全可以由 kset 代替，也就是說 sysfs 中只需要一種管理結構是 kset，一種代表具體物件的結構是 kobject，在 kobject 下再用屬性檔案表示這個物件所具有的屬性；

…

小結

    sysfs 給應用程式提供了統一訪問裝置的介面，但可以看到， sysfs 僅僅是提供了一個可以統一訪問裝置的框架，但究竟是否支援 sysfs 還需要各裝置驅動程式的程式設計支援；在 2.6 核心誕生 5年以來的發展中，很多子系統、裝置驅動程式逐漸轉向了 sysfs 作為與使用者空間友好的介面，但仍然也存在大量的程式碼還在使用舊的 proc 或虛擬字元裝置的 ioctl 方式；如果僅從終端使用者的角度來說， sysfs 與 proc 都是在提供相同或類似的功能，對於舊的 proc 程式碼，沒有絕對的必要去做 proc 至 sysfs 的升級；因此在可預見的將來， sysfs 會與 proc, debugfs, configfs 等共存很長一段時間。

linux2.6核心引入sysfs檔案系統，sysfs可以看成與proc,devfs和devpty同類別的檔案系統，該檔案系統是虛擬的檔案系統，可以更方便對系統裝置進行管理。它可以產生一個包含所有系統硬體層次檢視，與提供程序和狀態資訊的proc檔案系統十分類似。
sysfs把連線在系統上的裝置和匯流排組織成為一個分級的檔案，它們可以由使用者空間存取，向用戶空間匯出核心的資料結構以及它們的屬性。sysfs的一個目的就是展示裝置驅動模型中各元件的層次關係，其頂級目錄包括block,bus,drivers,class,power和firmware等.

sysfs 與 /sys

    sysfs 檔案系統總是被掛載在 /sys 掛載點上。雖然在較早期的2.6核心系統上並沒有規定 sysfs 的標準掛載位置，可以把 sysfs 掛載在任何位置，但較近的2.6核心修正了這一規則，要求 sysfs 總是掛載在 /sys 目錄上；針對以前的 sysfs 掛載位置不固定或沒有標準被掛載，有些程式從 /proc/mounts 中解析出 sysfs 是否被掛載以及具體的掛載點，這個步驟現在已經不需要了。請參考附錄給出的 sysfs-rules.txt 檔案連結。

    sysfs 與 proc

    sysfs 與 proc 相比有很多優點，最重要的莫過於設計上的清晰。一個 proc 虛擬檔案可能有內部格式，如 /proc/scsi/scsi ，它是可讀可寫的，(其檔案許可權被錯誤地標記為了 0444 ！，這是核心的一個BUG)，並且讀寫格式不一樣，代表不同的操作，應用程式中讀到了這個檔案的內容一般還需要進行字串解析，而在寫入時需要先用字串格式化按指定的格式寫入字串進行操作；相比而言， sysfs 的設計原則是一個屬性檔案只做一件事情， sysfs 屬性檔案一般只有一個值，直接讀取或寫入。整個 /proc/scsi 目錄在2.6核心中已被標記為過時(LEGACY)，它的功能已經被相應的 /sys 屬性檔案所完全取代。新設計的核心機制應該儘量使用 sysfs 機制，而將 proc 保留給純淨的“程序檔案系統”。

表 1. /sys 下的目錄結構

sysfs 是在這個 Linux 統一裝置模型的開發過程中的一項副產品(見 參考資料 中 Greg K. Hartman 寫作的 LinuxJournal 文章)。為了將這些有層次結構的裝置以使用者程式可見的方式表達出來，人們很自然想到了利用檔案系統的目錄樹結構（這是以 UNIX 方式思考問題的基礎，一切都是檔案！）在這個模型中，有幾種基本型別，它們的對應關係見 表 2. Linux 統一裝置模型的基本結構 ：

    表 2. Linux 統一裝置模型的基本結構

從核心在實現它們時所使用的資料結構來說， Linux 統一裝置模型又是以兩種基本資料結構進行樹型和連結串列型結構組織的：

    kobject: 在 Linux 裝置模型中最基本的物件，它的功能是提供引用計數和維持父子(parent)結構、平級(sibling)目錄關係，上面的 device, device_driver 等各物件都是以 kobject 基礎功能之上實現的；

struct kobject {
        const char              *name;
        struct list_head        entry;
        struct kobject          *parent;
        struct kset             *kset;
        struct kobj_type        *ktype;
        struct sysfs_dirent     *sd;
        struct kref             kref;
        unsigned int state_initialized:1;
	unsigned int state_in_sysfs:1;
        unsigned int state_add_uevent_sent:1;
        unsigned int state_remove_uevent_sent:1;
}; 

    其中 struct kref 內含一個 atomic_t 型別用於引用計數， parent 是單個指向父節點的指標， entry 用於父 kset 以連結串列頭結構將 kobject 結構維護成雙向連結串列；

    kset: 它用來對同類型物件提供一個包裝集合，在核心資料結構上它也是由內嵌一個 kboject 實現，因而它同時也是一個 kobject (面向物件 OOP 概念中的繼承關係) ，具有 kobject 的全部功能；

struct kset {
        struct list_head list;
        spinlock_t list_lock;
        struct kobject kobj;
        struct kset_uevent_ops *uevent_ops;
}; 

    其中的 struct list_head list 用於將集合中的 kobject 按 struct list_head entry 維護成雙向連結串列；

    涉及到檔案系統實現來說， sysfs 是一種基於 ramfs 實現的記憶體檔案系統，與其它同樣以 ramfs 實現的記憶體檔案系統(configfs,debugfs,tmpfs,...)類似， sysfs 也是直接以 VFS 中的 struct inode 和 struct dentry 等 VFS 層次的結構體直接實現檔案系統中的各種物件；同時在每個檔案系統的私有資料 (如 dentry->d_fsdata 等位置) 上，使用了稱為 struct sysfs_dirent 的結構用於表示 /sys 中的每一個目錄項。

struct sysfs_dirent {
        atomic_t                s_count;
        atomic_t                s_active;
        struct sysfs_dirent     *s_parent;
        struct sysfs_dirent     *s_sibling;
        const char              *s_name;
    union {
            struct sysfs_elem_dir           s_dir;
            struct sysfs_elem_symlink       s_symlink;
            struct sysfs_elem_attr          s_attr;
            struct sysfs_elem_bin_attr      s_bin_attr;
    };

    unsigned int            s_flags;
    ino_t                   s_ino;
    umode_t                 s_mode;
    struct iattr            *s_iattr;