devfs sysfs

linux下有专门的文件系统用来对设备进行管理，devfs和sysfs就是其中两种。

　　一、devfs

　　devfs是在2.4内核就出现了，它是用来解决linux中设备管理混乱的问题，你查看一下/dev下的设备文件就知道其中有许多是空的(也就是没有对应的硬件的)，但是它们却必须存在，所以这给linux设备管理带来了很多麻烦，为了解决这个问题，linux内核开发人员开发了devfs，并用一个守护进程devfsd来做一些与以前硬件驱动兼容的事情。

　　devfs和sysfs都是和proc一样，是一个虚拟的文件系统，向devfs注册的驱动程序，devfs将会在/dev下建立相应的设备文件；但是为了兼容，devfsd这个守护进程将会在某个设定的目录中建立以主设备号为索引的设备文件，如果不这么做，以前的许多应用将不能运行。

　　在2.6内核以前一直使用的是devfs，devfs挂载于/dev目录下，提供了一种类似于文件的方法来管理位于/dev目录下的所有设备，我们知道/dev目录下的每一个文件都对应的是一个设备，至于当前该设备存在与否先且不论，而且这些特殊文件是位于根文件系统上的，在制作文件系统的时候我们就已经建立了这些设备文件，因此通过操作这些特殊文件，可以实现与内核进行交互。

　　但是devfs文件系统有一些缺点，例如：不确定的设备映射，有时一个设备映射的设备文件可能不同，例如我的U盘可能对应sda有可能对应sdb；没有足够的主/辅设备号，当设备过多的时候，显然这会成为一个问题；/dev目录下文件太多而且不能表示当前系统上的实际设备；命名不够灵活，不能任意指定等等。

　　二、sysfs

　　sysfs是Linux 2.6所提供的一种虚拟文件系统。这个文件系统不仅可以把装置(devices)和驱动程式(drivers)的资讯从kernel space输出到user space，也可以用来对装置和驱动程式做设定。

　　sysfs的目的是把一些原本在procfs中的，关于装置的部份独立出来，以[装置阶层架构}(device tree)的形式呈现。这个档案系统由Patrick Mochel所写，稍后Maneesh Soni撰写 “sysfs backing store path”，以降低在大型系统中对内存的需求量。

　　sysfs一开始以ramfs为基础，也是一个只存在于内存中的档案系统。ramfs是在2.4核心处于稳定阶段时加入的。ramfs是一个优雅的实做，证明了要在当时仍很新的虚拟档案系统(VFS)下写一个简单的档案系统是多么容易的一件事。由于ramfs的简洁以及使用了VFS，稍后的一些内存形式的档案系统都以它作为开发基础。

　　sysfs刚开始被命名成ddfs(Device Driver Filesystem)，当初只是为了要对新的驱动程式模型除错而开发出来的。它在除错时，会把装置架构(device tree)的资讯输出到procfs档案系统中。但在Linus Torvalds的急切督促下，ddfs被转型成一个以ramfs为基础的档案系统。在新的驱动程式模型被整合进 2.5.1 核心时，ddfs 被改名成driverfs，以更确切描述它的用途。

　　在2.5核心开发的次年，新的‘驱动程式模型’和‘driverfs’证明了对核心中的其他子系统也有用处。kobjects被开发出来，作为核心物件的中央管理机制，而此时driverfs也被改名成sysfs。

　　正因为devfs上述这些问题的存在，在linux2.6内核以后，引入了一个新的文件系统sysfs，它挂载于/sys目录下，跟devfs一样它也是一个虚拟文件系统，也是用来对系统的设备进行管理的，它把实际连接到系统上的设备和总线组织成一个分级的文件，用户空间的程序同样可以利用这些信息以实现和内核的交互。

　　该文件系统是当前系统上实际设备树的一个直观反应，它是通过kobject子系统来建立这个信息的，当一个kobject被创建的时候，对应的文件和目录也就被创建了，位于/sys下的相关目录下，既然每个设备在sysfs中都有唯一对应的目录，那么也就可以被用户空间读写了。用户空间的工具udev就是利用了sysfs提供的信息来实现所有devfs的功能的，但不同的是udev运行在用户空间中，而devfs却运行在内核空间，而且udev不存在devfs那些先天的缺陷。很显然，sysfs将是未来发展的方向。

内核的结构化设备模型在用户空间就称为sysfs.它与procfs类似，二者都位于内存的文件系统中，而且包含内核数据结构的信息。但是，procfs是查看内核内部的一个通用视窗，而sysfs则特定的对应于设备模型。因而，sysfs并非procfs的替代品。进程描述符、sysctl参数等信息属于procfs而非sysfs。udev的大多数功能都取决于sysfs。
　　三、udev
　　udev是一种工具，它能够根据系统中的硬件设备的状况动态更新设备文件，包括设备文件的创建，删除等。设备文件通常放在/dev目录下，使用udev后,在/dev下面只包含系统中真实存在的设备。它于硬件平台无关的，位于用户空间，需要内核sysfs和tmpfs的支持，sysfs为udev提供设备入口和uevent通道，tmpfs为udev设备文件提供存放空间。
四、实例sysfs
trace 的程式是 cpufreq，推薦一下這個程式，裡面有完整的 kobject initial、如何套到一個 sys_device 上、ktype的宣告等。裡面也有一些不錯的寫程式技巧，減低了重覆宣告 kyte 的 attribute 和 ops(這些技巧在kernel code中常出現，想必是不錯的撰寫風格)，想了解 sysfs 的話，我想 cpufreq 算是不錯的範例格式。

kobject: 最小的 device model unit。單純地宣告一個 kobject 並沒什麼用處，他最神奇的地方是內嵌在 Kernel 的 device 資料結構中，例如 character device(cdev), block device(blkdev)。這些資料結構中都會內嵌一個 kobject.

ktype: kobject 的集合。但它比較偏向收集相同 operation 的 kobject 的一個集合，也就是說它是負責管理這一群 kobjects 的 operation. (show,store)。kobject 會利用它了辨識自已是屬於那一個類型，然後在 /sys 下建立正確的目錄位置。

kset: kobject 的集合。這也是一個集合，不同於ktype，它不管理 kobject 的 ops，最重要的是建立上層(sub-system)和下層的(kobject)的關聯性。kobject 也會利用它了辨識自已是屬於那一個類型，然後在 /sys 下建立正確的目錄位置。而 kset 的優先權比較高，kobject 會利用自已的 *kset 找到自已所屬的kset，並把 *ktype 指定成該kset下的ktype，當然，你也是可以搞鬼，設定了kset，但用不同的ktype的operation(…有些code是這樣)。除非沒有定義kset，才會用 ktype 來建立關聯。

subsystem:如果說 kset 是管理 kobject 的集合，同理、subsystem 就是管理 kset 的集合。

attribute: 建立了 kobject 並成功註冊之後，你會發現出現該 kobj 對應的目錄竟然是空的(這是當然的啦 XD)，要如何產生資訊檔案，就是利用 attribute 這個資料結構。
struct attribute {
char *name; // 以該變數為檔名出現在 kobj 的目錄下
struct module *owner; // THIS_MODULE
mode_t mode; //permission, “S_IRUGO” or “S_IWUSR” or “0660”
};
應該是的出來 attribute 的功用，建立好attribute之後，讀取/寫入該檔案會呼叫 ktype 對應的 operation.