參考博客：http://blog.csdn.net/fudan_abc/archive/2007/09/01/1768277.aspx
在2.6內核版本以上就多了sysfs文件系統，主要功能：
- 電源管理和系統關機
這些需要一個對系統的結構的理解. 例如, 一個 USB 宿主適配器不可能被關閉, 在處理所有的連接到這個適配器的設備之前. 這個設備模型使能了一個按照正確順序的系統硬件的遍歷.
- 與用戶空間的通訊
sysfs 虛擬文件系統的實現被緊密地捆綁進設備模型, 並且暴露它所代表的結構. 關於系統到用戶空間的信息提供和改變操作參數的旋紐正越來越多地通過 sysfs 和 通過設備模型來完成.
- 可熱插拔設備
計算機硬件正更多地動態變化; 外設可因用戶的一時念頭而進出. 在內核中使用的來處理和(特別的)與用戶空間關於設備插入和拔出的通訊, 是由設備模型來管理.
- 設備類別
系統的許多部分對設備如何連接沒有興趣, 但是它們需要知道什麼類型的設備可用. 設備模型包括一個機制來分配設備給類別, 它在一個更高的功能性的級別描述了這些設備, 並且允許它們從用戶空間被發現.
- 對象生命期
許多上面描述的功能, 包括熱插拔支持和 sysfs, 使在內核中創建和操作對象複雜了. 設備模型的實現要求創建一套機制來處理對象生命期, 它們之間的關係, 和它們在用戶空間的表示.
（linux設備驅動第三版）
用subsystem管理kset集合，kset管理kobject集合
subsystem->kset管理kset->kobject ,kset->list管理kobject
主要函數：
kobject_register->kobject_add,kobject_unregister->kobject_del
kset_register,subsystem_register都添加自身對象到上一級
爲實現特定的組織結構而引入的結構功能結構，只要某個結構包含了這個功能結構也就具有了這個功能，例子很多:kref,應用計數，list_head，鏈表。。等等
kset具有list就有了管理個個kobject功能，而kset有有kobject所以也可以被其他的kset管理，而其上層往往是subsystem結構
同樣的subsystem包含kset，而kset又包含kobject所以subsystem也有被管理的屬性
ldd3的examples：
首先明白內核中已經存在全局變量subsystem結構的bus_subsys，因爲是頂層(一般全局變量都是頂層），所以不表現爲kobject的被管理屬性，而是kset的管理屬性，用於管理ldd3的subsys，所以還穿在class_subsys,等subsystem的全局變量，
相關函數其實就是調用了兩個註冊函數，bus_register(), device_register()。bus_create_file()是在sysfs下創建一個文件夾，
因爲定義了
struct bus_type ldd_bus_type = {
.name = "ldd",
.match = ldd_match,
.hotplug = ldd_hotplug,
};
struct device ldd_bus = {
.bus_id = "ldd0",
.release = ldd_bus_release
};
ldd_bus即使總線，又是設備
bus_register()，向系統註冊ldd_bus_type這個總線類型。bus_create_file()這個就是向sysfs中創建一個文件。device_register()系統註冊ldd_bus這個硬件類型。
device_register()的代碼，它也是向devices_subsys這個subsystem註冊
所以說bus_register()，device_register(),driver_regedist(),等函數都是對sysfs文件系統的操作，最終都要調用kobject_register或kobject_add,都是頂層的向bus_sys,devices_sys,drivers_sys全局變量註冊kobject,除了對kobject的操作外，device_register(),driver_regedist(),兩個函數還分別去bus的devices和drivers中尋找相應的設備和驅動，並且調用prode
可以認爲因爲結構從kobject到kset在到subsystem在到ldd_bus結構擴展了，函數也從kobject->register,在到kset->。。。。到bus_register，，函數也擴展了，因爲要設置的參數變多了，所以瞭解了功能結構是對上層的理解很有幫助。
sysfs文件系統就說到這裏了，，想進一步瞭解就去看上面我給的網址了