Linux設(shè)備模型中三個(gè)很重要的概念就是總線,設(shè)備,驅(qū)動(dòng).即bus,device,driver,而實(shí)際上內(nèi)核中也定義了這么一些數(shù)據(jù)結(jié)構(gòu),他們是struct bus_type,struct device,struct device_driver,這三個(gè)重要的數(shù)據(jù)結(jié)構(gòu)都來(lái)自一個(gè)地方,include/linux/device.h.我們知道總線有很多種,pci總線,scsi總線,usb總線,所以我們會(huì)看到Linux內(nèi)核代碼中出現(xiàn)pci_bus_type,scsi_bus_type,usb_bus_type,他們都是struct bus_type類(lèi)型的變量.而struct bus_type結(jié)構(gòu)中兩個(gè)非常重要的成員就是struct kset drivers和struct kset devices.kset和另一個(gè)叫做kobject正是Linux Kernel 2.6中設(shè)備模型的基本元素,但此處我們卻不愿多講,因?yàn)闀簳r(shí)不用去認(rèn)識(shí)他們.我們的生命中會(huì)遇見(jiàn)許許多多的人和事,但更多的人和事與我們只是擦肩而過(guò),只是我們生命中的過(guò)客而已.在我們?nèi)松碾娪爸?他們也許只有一個(gè)鏡頭,甚至那一個(gè)鏡頭后來(lái)也被剪輯掉了.這里我們只需要知道,drivers和devices的存在,讓struct bus_type與兩個(gè)鏈表聯(lián)系了起來(lái),一個(gè)是devices的鏈表,一個(gè)是drivers的鏈表,也就是說(shuō),知道一條總線所對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu),就可以找到這條總線所關(guān)聯(lián)的設(shè)備有哪些,又有哪些支持這類(lèi)設(shè)備的驅(qū)動(dòng)程序.

而要實(shí)現(xiàn)這些,就要求每次出現(xiàn)一個(gè)設(shè)備就要向總線匯報(bào),或者說(shuō)注冊(cè),每次出現(xiàn)一個(gè)驅(qū)動(dòng),也要向總線匯報(bào),或者說(shuō)注冊(cè).比如系統(tǒng)初始化的時(shí)候,會(huì)掃描連接了哪些設(shè)備,并為每一個(gè)設(shè)備建立起一個(gè)struct device的變量,每一次有一個(gè)驅(qū)動(dòng)程序,就要準(zhǔn)備一個(gè)struct device_driver結(jié)構(gòu)的變量.把這些變量統(tǒng)統(tǒng)加入相應(yīng)的鏈表,device插入devices鏈表,driver插入drivers鏈表. 這樣通過(guò)總線就能找到每一個(gè)設(shè)備,每一個(gè)驅(qū)動(dòng).

然而,假如計(jì)算機(jī)里只有設(shè)備卻沒(méi)有對(duì)應(yīng)的驅(qū)動(dòng),那么設(shè)備無(wú)法工作.反過(guò)來(lái),倘若只有驅(qū)動(dòng)卻沒(méi)有設(shè)備,驅(qū)動(dòng)也起不了任何作用.在他們遇見(jiàn)彼此之前,雙方都如同路埂的野草,一個(gè)飄啊飄,一個(gè)搖啊搖,誰(shuí)也不知道未來(lái)在哪里,只能在生命的風(fēng)里飄搖.于是總線上的兩張表里就慢慢的就掛上了那許多孤單的靈魂.devices開(kāi)始多了,drivers開(kāi)始多了,他們像是兩個(gè)來(lái)自世界,devices們彼此取暖,drivers們一起狂歡,但他們有一點(diǎn)是相同的,都只是在等待屬于自己的那個(gè)另一半.

看代碼的我,一直好奇的想知道,他們是否和我們現(xiàn)實(shí)中一樣,有些人注定是等別人,而有些人是注定被人等的.

struct bus_type中為devices和drivers準(zhǔn)備了兩個(gè)鏈表,而代表device的結(jié)構(gòu)體struct device中又有兩個(gè)成員,struct bus_type *bus和struct device_driver *driver,同樣,代表driver的結(jié)構(gòu)體struct device_driver同樣有兩個(gè)成員,struct bus_type *bus和struct list_head devices,struct device和struct device_driver的定義和struct bus_type一樣,在include/linux/device.h中.憑一種男人的直覺(jué),可以知曉,struct device中的bus記錄的是這個(gè)設(shè)備連在哪條總線上,driver記錄的是這個(gè)設(shè)備用的是哪個(gè)驅(qū)動(dòng),反過(guò)來(lái),struct device_driver中的bus代表的也是這個(gè)驅(qū)動(dòng)屬于哪條總線,devices記錄的是這個(gè)驅(qū)動(dòng)支持的那些設(shè)備,沒(méi)錯(cuò),是devices(復(fù)數(shù)),而不是device(單數(shù)),因?yàn)橐粋€(gè)驅(qū)動(dòng)程序可以支持一個(gè)或多個(gè)設(shè)備,反過(guò)來(lái)一個(gè)設(shè)備則只會(huì)綁定給一個(gè)驅(qū)動(dòng)程序.

1. 于是我們想知道,關(guān)于bus,關(guān)于device,關(guān)于driver,他們是如何建立聯(lián)系的呢?換言之,這三個(gè)數(shù)據(jù)結(jié)構(gòu)中的指針是如何被賦值的?絕對(duì)不可能發(fā)生的事情是,一旦為一條總線申請(qǐng)了一個(gè)struct bus_type的數(shù)據(jù)結(jié)構(gòu)之后,它就知道它的devices鏈表和drivers鏈表會(huì)包含哪些東西,這些咚咚一定不會(huì)是先天就有的,只能是后天填進(jìn)來(lái)的.而具體到usb系統(tǒng),完成這個(gè)工作的就是usb core.usb core的代碼會(huì)進(jìn)行整個(gè)usb系統(tǒng)的初始化,比如申請(qǐng)struct bus_type usb_bus_type,然后會(huì)掃描usb總線,看線上連接了哪些usb設(shè)備,或者說(shuō)root hub上連了哪些usb設(shè)備,比如說(shuō)連了一個(gè)usb鍵盤(pán),那么就為它準(zhǔn)備一個(gè)struct device,根據(jù)它的實(shí)際情況,為這個(gè)struct device賦值,并插入devices鏈表中來(lái).又比如root hub上連了一個(gè)普通的hub,那么除了要為這個(gè)hub本身準(zhǔn)備一個(gè)struct device以外,還得繼續(xù)掃描看這個(gè)hub上是否又連了別的設(shè)備,有的話(huà)繼續(xù)重復(fù)之前的事情,這樣一直進(jìn)行下去,直到完成整個(gè)掃描,最終就把usb_bus_type中的devices鏈表給建立了起來(lái).

那么drivers鏈表呢?這個(gè)就不用bus方面主動(dòng)了,而該由每一個(gè)driver本身去bus上面登記,或者說(shuō)掛牌.具體到usb系統(tǒng),每一個(gè)usb設(shè)備的驅(qū)動(dòng)程序都會(huì)有一個(gè)struct usb_driver結(jié)構(gòu)體,其代碼如下,來(lái)自include/linux/usb.h

    485 /* -------------------------------------------------------------------------- */
    486
    487 /**
    488  * struct usb_driver - identifies USB driver to usbcore
    489  * @owner: Pointer to the module owner of this driver; initialize
    490  *      it using THIS_MODULE.
    491  * @name: The driver name should be unique among USB drivers,
    492  *      and should normally be the same as the module name.
    493  * @probe: Called to see if the driver is willing to manage a particular
    494  *      interface on a device.  If it is, probe returns zero and uses
    495  *      dev_set_drvdata() to associate driver-specific data with the
    496  *      interface.  It may also use usb_set_interface() to specify the
    497  *      appropriate altsetting.  If unwilling to manage the interface,
    498  *      return a negative errno value.
    499  * @disconnect: Called when the interface is no longer accessible, usually
    500  *      because its device has been (or is being) disconnected or the
    501  *      driver module is being unloaded.
    502  * @ioctl: Used for drivers that want to talk to userspace through
    503  *      the "usbfs" filesystem.  This lets devices provide ways to
    504  *      expose information to user space regardless of where they
    505  *      do (or don't) show up otherwise in the filesystem.
    506  * @suspend: Called when the device is going to be suspended by the system.
    507  * @resume: Called when the device is being resumed by the system.
    508  * @id_table: USB drivers use ID table to support hotplugging.
    509  *      Export this with MODULE_DEVICE_TABLE(usb,...).  This must be set
    510  *      or your driver's probe function will never get called.
    511  * @driver: the driver model core driver structure.
    512  *
    513  * USB drivers must provide a name, probe() and disconnect() methods,
    514  * and an id_table.  Other driver fields are optional.
    515  *
    516  * The id_table is used in hotplugging.  It holds a set of descriptors,
    517  * and specialized data may be associated with each entry.  That table
    518  * is used by both user and kernel mode hotplugging support.
    519  *
    520  * The probe() and disconnect() methods are called in a context where
    521  * they can sleep, but they should avoid abusing the privilege.  Most
    522  * work to connect to a device should be done when the device is opened,
    523  * and undone at the last close.  The disconnect code needs to address
    524  * concurrency issues with respect to open() and close() methods, as
    525  * well as forcing all pending I/O requests to complete (by unlinking
    526  * them as necessary, and blocking until the unlinks complete).
    527  */
    528 struct usb_driver {
    529         struct module *owner;
    530
    531         const char *name;
    532
    533         int (*probe) (struct usb_interface *intf,
    534                       const struct usb_device_id *id);
    535
    536         void (*disconnect) (struct usb_interface *intf);
    537
    538         int (*ioctl) (struct usb_interface *intf, unsigned int code, void *buf);
    539
    540         int (*suspend) (struct usb_interface *intf, u32 state);
    541         int (*resume) (struct usb_interface *intf);
    542
    543         const struct usb_device_id *id_table;
    544
    545         struct device_driver driver;
    546 };
    547 #define to_usb_driver(d) container_of(d, struct usb_driver, driver)
  看似很長(zhǎng)一段,實(shí)際上也就是注釋為主.而此刻我們只需注意到其中的struct device_driver driver這個(gè)成員,usb core為每一個(gè)設(shè)備驅(qū)動(dòng)準(zhǔn)備了一個(gè)函數(shù),讓它把自己的這個(gè)struct device_driver driver插入到usb_bus_type中的drivers鏈表中去.而這個(gè)函數(shù)正是我們此前看到的usb_register.而與之對(duì)應(yīng)的usb_deregister所從事的正是與之相反的工作,把這個(gè)結(jié)構(gòu)體從drivers鏈表中刪除.可以說(shuō),usb core的確是用心良苦,為每一個(gè)usb設(shè)備驅(qū)動(dòng)做足了功課,正因?yàn)槿绱?作為一個(gè)實(shí)際的usb設(shè)備驅(qū)動(dòng),它在初始化階段所要做的事情就很少,很簡(jiǎn)單了,直接調(diào)用usb_register即可.事實(shí)上,沒(méi)有人是理所當(dāng)然應(yīng)該為你做什么的,但usb core這么做了.所以每一個(gè)寫(xiě)usb設(shè)備驅(qū)動(dòng)的人應(yīng)該銘記,usb device driver絕不是一個(gè)人在工作,在他身后,是usb core所提供的默默無(wú)聞?dòng)植豢苫蛉钡闹С?