2.6核心引入了input字系統，usb子系統，misc子系統等一系列字元裝置子系統，在熟練掌握這些子系統之後，我們來看一下linux核心設計這麼些子系統的意義何在？可以連線的裝置越來越多，這些裝置的種類也越來越雜，傳統的字元裝置/塊裝置的分類已經不能滿足要求，以字元裝置為例，現在的linux字元裝置體系已經不能代表所有支援的字元裝置的最小交集，況且，在隨著裝置的增多，越來越長的線性裝置鍊錶給管理帶來了諸多不便，因此「需要增加乙個層」來給字元裝置體系解除安裝一些壓力了，於是就將所有的「一類」裝置總結成「乙個」裝置，然後將這乙個裝置作為字元裝置加入鍊錶，而真正的字元裝置需要新設計的「層」來管理了，在重新設計之後，被總結出來的「那個」字元裝置已經不再是傳統的裝置了，而是「裝置類」了，同時，/dev目錄下也有了相應的「裝置類」，比如/dev/input，這個下面有一系列檔案，其中有些檔案就代表上面所說的「裝置類」，比如mice就是所有的滑鼠，而還有些檔案代表真實的裝置，比如mouse0，mouse1之類的。從應用的角度來看，input子系統確實解除安裝了字元裝置系統的壓力，只因新增了乙個層，至於這種層該如何實現，還是要看**：
static int __init input_init(void)
static const struct file_operations input_fops = ;
static int input_open_file(struct inode *inode, struct file *file)
由上述字元裝置體系的**可見，被解除安裝的真正的字元裝置需要input層來集中實現。可以想見，input子系統中乙個裝置類就應該有乙個handler，由裝置檔案inode得到的minor來索引，我們看乙個例子：
# stat mice
file: `mice'
size: 0 blocks: 0 io block: 4096 character special file
device: 1607h/5639d inode: 23921566 links: 1 device type: d,3f #主裝置號為0xd，次裝置號為0x3f
...注意主次裝置號，input子系統將整個裝置號空間按照高3位分割成了8個子空間，每乙個子空間代表input子系統中一類裝置的所有裝置。
static int __init mousedev_init(void)
mousedev_init只是初始化了input子系統中滑鼠裝置的框架，然後通過mousedev_create建立了乙個通用的滑鼠類，那麼真實的滑鼠類檔案何時建立呢？每一類input裝置都有乙個input_handler，對於滑鼠就是mousedev_handler，它通過mousedev_init註冊進系統，所有的handler形成乙個鍊錶，同時系統中input子系統還擁有另一條鍊錶，那就是input裝置，每當有新的裝置插入機器時，在更底層的裝置驅動知道這是乙個input裝置時，就將之納入input子系統的管理，也就是初始化乙個input_dev，然後將之鏈結進input_dev鍊錶，隨後遍歷input_handler鍊錶，在找到「可以處理該裝置」的input_handler之後呼叫其connect方法，對於滑鼠那就是mousedev_connect，在mousedev_connect中會初始化乙個滑鼠裝置：mousedev_create：
static struct mousedev *mousedev_create(struct input_dev *dev, struct input_handler *handler, int minor)
input子系統中input_dev鍊錶和input_handler鍊錶相認的過程和底層bus中的的device鍊錶和device_driver鍊錶相認的過程幾乎是一樣的，運用了相同的思想。在device和device_driver的層次，頂多在pci的層次，由probe函式呼叫input子系統的初始化規程，比如分配input_dev，註冊中斷等等，註冊好input_dev之後，該裝置就被納入input子系統的管轄了，整個層次是device--pci...--input_dev--input_handler--input字元裝置--/dev/input/***，在中斷發生的時候，中斷處理程式會從引數中得到input_dev，然後就可以用input_report_xx來報告了，該報告可以順著剛剛說過的層次線索一直到達使用者空間需要該中斷結果的地方，比如移動了一下滑鼠的中斷會被xwindow來使用。
input子系統僅僅是乙個解除安裝原始結構壓力的乙個例子，諸如usb子系統，sound子系統以及misc子系統都是這樣實現的，給你的感覺並沒有什麼不一樣，如果所有的字元裝置統統直接在chrdev框架下實現，/dev下將被建立所有的字元裝置，如果很多字元被分類了，比如分到了input類中，或者分到了usb類中，那麼每乙個裝置依然擁有乙個/dev下的字元裝置檔案，只是位置不同了，可能被放入了input，usb子目錄下，stat的結果仍然是character special file，沒有什麼不同，在使用sysfs/udevd的情況下，你甚至可以不建立input，usb等子目錄，依然將所有檔案建立在/dev目錄下也沒什麼不可。注意，input/usb/misc等子系統僅僅規整了核心裝置驅動的結構，這種規整對於使用者空間是透明的。我感覺，linux核心的這種規整最能體現計算機業的一句真理，那就是「加乙個層次」，linux核心通過引入新的層次，在不改變原有字元驅動結構的情況下，成功將幾個新的分類驅動層次插入到了既有的框架，這同時也說明了linux核心中字元裝置框架原本的靈活性。
linux分類驅動對字元裝置框架壓力的解除安裝
2.6核心引入了input字系統，usb子系統，misc子系統等一系列字元裝置子系統，在熟練掌握這些子系統之後，我們來看一下linux核心設計這麼些子系統的意義何在？可以連線的裝置越來越多，這些裝置的種類也越來越雜，傳統的字元裝置 塊裝置的分類已經不能滿足要求，以字元裝置為例，現在的linux字元裝...
Linux驅動裝置分類
1.字元驅動裝置 指訪問時沒有快取的裝置，採用位元組流訪問的裝置，如按鍵，串列埠，音效卡，觸控螢幕等 2.塊驅動裝置 有快取來支援，塊裝置必須能夠隨機訪問 random access 字元裝置則沒有這個要求。unix下，採用乙個資料塊來進行訪問，資料塊一般為512位元組，1k等，linux下，可以採...
Linux裝置驅動分類
linux系統的裝置分為字元裝置 char device 塊裝置 block device 和網路裝置 network device 三種。字元裝置是指訪問時沒有快取的裝置。塊裝置的讀寫都有快取來支援，並且塊裝置必須能夠隨機訪問 random access 字元裝置則沒有這個要求。典型的字元裝置包括...