上節我們分析設備驅動模型中的device,主要是drivers/base/core.c,可以說是代碼量最大的一個文件。本節要分析的驅動driver,就要相對簡單很多。原因也很簡單,對於driver,我們能定義的公共部分實在不多,能再sysfs中表達的也很少。本節的分析將圍繞drivers/base/driver.c,但頭文件仍然是include/linux/device.h和drivers/base/base.h。
先讓我們來看看driver的結構。
struct device_driver {
const char *name;
struct bus_type *bus;
struct module *owner;
const char *mod_name; /* used for built-in modules */
bool suppress_bind_attrs; /* disables bind/unbind via sysfs */
int (*probe) (struct device *dev);
int (*remove) (struct device *dev);
void (*shutdown) (struct device *dev);
int (*suspend) (struct device *dev, pm_message_t state);
int (*resume) (struct device *dev);
const struct attribute_group **groups;
const struct dev_pm_ops *pm;
struct driver_private *p;
};
struct device_driver就是模型定義的通用驅動結構。name是驅動名稱,但這個name也只是在靜態定義的初始名稱,實際使用的名稱還是由kobject中保管的。bus執行驅動所在的總線,owner是驅動所在的模塊,還有一個所在模塊名稱mod_name,suppress_bind_attrs定義是否允許驅動通過sysfs決定掛載還是卸載設備。下面是一系列函數指針,probe是在驅動剛與設備掛接時調用的,remove是在設備卸載時調用的,shutdown是在設備關閉時調用的(說實話我現在還不知道remove和shutdown的區別),suspend是設備休眠時調用的,resume是設備恢復時調用的。group是屬性集合,pm是電源管理的函數集合,p是指向driver_private的指針。
struct driver_private {
struct kobject kobj;
struct klist klist_devices;
struct klist_node knode_bus;
struct module_kobject *mkobj;
struct device_driver *driver;
};
#define to_driver(obj) container_of(obj, struct driver_private, kobj)
與device類似,device_driver把與其它組件聯繫的大部分結構變量移到struct driver_private中來。首先是kobj,在sysfs中代表driver目錄本身。klist_devices是驅動下的設備鏈表,knode_bus是要掛載在總線的驅動鏈表上的節點。mkobj是driver與相關module的聯繫,之前在device_driver結構中已經有指向module的指針,但這還不夠,在/sys下你能發現一個module目錄,所以驅動所屬的模塊在sysfs中也有顯示,具體留到代碼中再看。driver指針自然是從driver_private指回struct device_driver的。
struct driver_attribute {
struct attribute attr;
ssize_t (*show)(struct device_driver *driver, char *buf);
ssize_t (*store)(struct device_driver *driver, const char *buf,
size_t count);
};
#define DRIVER_ATTR(_name, _mode, _show, _store) \
struct driver_attribute driver_attr_##_name = \
__ATTR(_name, _mode, _show, _store)
除了以上兩個結構,還有struct driver_attribute。driver_attribute是driver對struct attribute的封裝,添加了兩個特用於device_driver的讀寫函數。這種封裝看似簡單重複,工作量很小,但在使用時卻會造成巨大的便利。
好,結構介紹完畢,下面看driver.c中的實現。
static struct device *next_device(struct klist_iter *i)
{
struct klist_node *n = klist_next(i);
struct device *dev = NULL;
struct device_private *dev_prv;
if (n) {
dev_prv = to_device_private_driver(n);
dev = dev_prv->device;
}
return dev;
}
int driver_for_each_device(struct device_driver *drv, struct device *start,
void *data, int (*fn)(struct device *, void *))
{
struct klist_iter i;
struct device *dev;
int error = 0;
if (!drv)
return -EINVAL;
klist_iter_init_node(&drv->p->klist_devices, &i,
start ? &start->p->knode_driver : NULL);
while ((dev = next_device(&i)) && !error)
error = fn(dev, data);
klist_iter_exit(&i);
return error;
}
struct device *driver_find_device(struct device_driver *drv,
struct device *start, void *data,
int (*match)(struct device *dev, void *data))
{
struct klist_iter i;
struct device *dev;
if (!drv)
return NULL;
klist_iter_init_node(&drv->p->klist_devices, &i,
(start ? &start->p->knode_driver : NULL));
while ((dev = next_device(&i)))
if (match(dev, data) && get_device(dev))
break;
klist_iter_exit(&i);
return dev;
}
driver_for_each_device()是對drv的設備鏈表中的每個設備調用一次指定函數。
driver_find_device()是在drv的設備鏈表中尋找一個設備,尋找使用指定的匹配函數。
這兩個函數都不陌生,在之前分析device的core.c中已經見到與它們很類似的函數,只不過那裏是遍歷設備的子設備鏈表,這裏是遍歷驅動的設備鏈表。next_device()同樣是輔助用的內部函數。
int driver_create_file(struct device_driver *drv,
struct driver_attribute *attr)
{
int error;
if (drv)
error = sysfs_create_file(&drv->p->kobj, &attr->attr);
else
error = -EINVAL;
return error;
}
void driver_remove_file(struct device_driver *drv,
struct driver_attribute *attr)
{
if (drv)
sysfs_remove_file(&drv->p->kobj, &attr->attr);
}
driver_create_file()創建drv下的屬性文件,調用sysfs_create_file()實現。
driver_remove_file()刪除drv下的屬性文件,調用sysfs_remove_file()實現。
static int driver_add_groups(struct device_driver *drv,
const struct attribute_group **groups)
{
int error = 0;
int i;
if (groups) {
for (i = 0; groups[i]; i++) {
error = sysfs_create_group(&drv->p->kobj, groups[i]);
if (error) {
while (--i >= 0)
sysfs_remove_group(&drv->p->kobj,
groups[i]);
break;
}
}
}
return error;
}
static void driver_remove_groups(struct device_driver *drv,
const struct attribute_group **groups)
{
int i;
if (groups)
for (i = 0; groups[i]; i++)
sysfs_remove_group(&drv->p->kobj, groups[i]);
}
driver_add_groups()在drv目錄下添加屬性集合,調用sysfs_create_groups()實現。
driver_remove_groups()在drv目錄下刪除屬性集合,調用sysfs_remove_groups()實現。
發現兩點問題:第一,是不是覺得driver_add_groups()不太合適,最好改爲driver_create_groups()才搭調。但不只是driver用driver_add_groups(),device也使用device_add_groups(),不知一處這樣做。第二,有沒有發現driver_create_file()是外部函數,driver_add_groups()就是內部函數,也就是說driver只對外提供添加屬性的接口,卻不提供添加屬性集合的接口。理由嗎?在struct device_driver()已經專門定義了一個groups變量來添加屬性集合,後面就不易再重複提供接口,而且創建屬性集合需要的操作遠比創建屬性費時。在device中也是這樣做的。
另外,driver中只提供管理屬性文件的方法,卻不提供管理二進制屬性文件的方法,這是因爲驅動本身沒有這種需求,只有部分設備纔要求二進制文件表示。
struct device_driver *get_driver(struct device_driver *drv)
{
if (drv) {
struct driver_private *priv;
struct kobject *kobj;
kobj = kobject_get(&drv->p->kobj);
priv = to_driver(kobj);
return priv->driver;
}
return NULL;
}
void put_driver(struct device_driver *drv)
{
kobject_put(&drv->p->kobj);
}
get_driver()增加drv的引用計數,put_driver()減少drv的引用計數。這都是通過drv->p->kobj來做的。
struct device_driver *driver_find(const char *name, struct bus_type *bus)
{
struct kobject *k = kset_find_obj(bus->p->drivers_kset, name);
struct driver_private *priv;
if (k) {
priv = to_driver(k);
return priv->driver;
}
return NULL;
}
driver_find()從bus的驅動鏈表中尋找特定名稱的driver。
/**
* driver_register - register driver with bus
* @drv: driver to register
*
* We pass off most of the work to the bus_add_driver() call,
* since most of the things we have to do deal with the bus
* structures.
*/
int driver_register(struct device_driver *drv)
{
int ret;
struct device_driver *other;
BUG_ON(!drv->bus->p);
if ((drv->bus->probe && drv->probe) ||
(drv->bus->remove && drv->remove) ||
(drv->bus->shutdown && drv->shutdown))
printk(KERN_WARNING "Driver '%s' needs updating - please use "
"bus_type methods\n", drv->name);
other = driver_find(drv->name, drv->bus);
if (other) {
put_driver(other);
printk(KERN_ERR "Error: Driver '%s' is already registered, "
"aborting...\n", drv->name);
return -EBUSY;
}
ret = bus_add_driver(drv);
if (ret)
return ret;
ret = driver_add_groups(drv, drv->groups);
if (ret)
bus_remove_driver(drv);
return ret;
}
driver_register()將drv註冊到系統中。它真是做得難以預料地簡單,所有的工作幾乎完全是由bus_add_driver()代爲完成的。但你要注意,在調用driver_register()前,drv->bus一定要預先設置。device可以不綁定bus,但driver一定要綁定到bus上。
void driver_unregister(struct device_driver *drv)
{
if (!drv || !drv->p) {
WARN(1, "Unexpected driver unregister!\n");
return;
}
driver_remove_groups(drv, drv->groups);
bus_remove_driver(drv);
}
driver_unregister()將drv從系統中撤銷。大部分工作是調用bus_remove_driver()完成的。可以看出bus_add_driver()與bus_remove_driver()相對。driver和bus的聯繫如此緊密,以至於driver的註冊和撤銷工作都可以由bus代勞了。我們需要更進一步的分析。
經過調查,我們發現很有一部分driver的代碼被移動到了bus.c中。我們本節是以driver爲主,所以接下來會盡量在不驚動bus的情況下,分析存在於bus.c中的driver代碼。
static ssize_t drv_attr_show(struct kobject *kobj, struct attribute *attr,
char *buf)
{
struct driver_attribute *drv_attr = to_drv_attr(attr);
struct driver_private *drv_priv = to_driver(kobj);
ssize_t ret = -EIO;
if (drv_attr->show)
ret = drv_attr->show(drv_priv->driver, buf);
return ret;
}
static ssize_t drv_attr_store(struct kobject *kobj, struct attribute *attr,
const char *buf, size_t count)
{
struct driver_attribute *drv_attr = to_drv_attr(attr);
struct driver_private *drv_priv = to_driver(kobj);
ssize_t ret = -EIO;
if (drv_attr->store)
ret = drv_attr->store(drv_priv->driver, buf, count);
return ret;
}
static struct sysfs_ops driver_sysfs_ops = {
.show = drv_attr_show,
.store = drv_attr_store,
};
看到這裏,你終於覺得driver開始正常了,它還要定義sysfs讀寫時操作的函數。
static void driver_release(struct kobject *kobj)
{
struct driver_private *drv_priv = to_driver(kobj);
pr_debug("driver: '%s': %s\n", kobject_name(kobj), __func__);
kfree(drv_priv);
}
static struct kobj_type driver_ktype = {
.sysfs_ops = &driver_sysfs_ops,
.release = driver_release,
};
與device的釋放函數device_release不同,driver_release沒有提供外界代碼運行的機會,只是簡單地釋放drv_priv函數。
/* Manually detach a device from its associated driver. */
static ssize_t driver_unbind(struct device_driver *drv,
const char *buf, size_t count)
{
struct bus_type *bus = bus_get(drv->bus);
struct device *dev;
int err = -ENODEV;
dev = bus_find_device_by_name(bus, NULL, buf);
if (dev && dev->driver == drv) {
if (dev->parent) /* Needed for USB */
down(&dev->parent->sem);
device_release_driver(dev);
if (dev->parent)
up(&dev->parent->sem);
err = count;
}
put_device(dev);
bus_put(bus);
return err;
}
static DRIVER_ATTR(unbind, S_IWUSR, NULL, driver_unbind);
/*
* Manually attach a device to a driver.
* Note: the driver must want to bind to the device,
* it is not possible to override the driver's id table.
*/
static ssize_t driver_bind(struct device_driver *drv,
const char *buf, size_t count)
{
struct bus_type *bus = bus_get(drv->bus);
struct device *dev;
int err = -ENODEV;
dev = bus_find_device_by_name(bus, NULL, buf);
if (dev && dev->driver == NULL && driver_match_device(drv, dev)) {
if (dev->parent) /* Needed for USB */
down(&dev->parent->sem);
down(&dev->sem);
err = driver_probe_device(drv, dev);
up(&dev->sem);
if (dev->parent)
up(&dev->parent->sem);
if (err > 0) {
/* success */
err = count;
} else if (err == 0) {
/* driver didn't accept device */
err = -ENODEV;
}
}
put_device(dev);
bus_put(bus);
return err;
}
static DRIVER_ATTR(bind, S_IWUSR, NULL, driver_bind);
上面描述了driver下兩個只寫的屬性文件,unbind和bind。應該是提供用戶空間命令是否將設備與驅動掛接的接口。
static int driver_add_attrs(struct bus_type *bus, struct device_driver *drv)
{
int error = 0;
int i;
if (bus->drv_attrs) {
for (i = 0; attr_name(bus->drv_attrs[i]); i++) {
error = driver_create_file(drv, &bus->drv_attrs[i]);
if (error)
goto err;
}
}
done:
return error;
err:
while (--i >= 0)
driver_remove_file(drv, &bus->drv_attrs[i]);
goto done;
}
static void driver_remove_attrs(struct bus_type *bus,
struct device_driver *drv)
{
int i;
if (bus->drv_attrs) {
for (i = 0; attr_name(bus->drv_attrs[i]); i++)
driver_remove_file(drv, &bus->drv_attrs[i]);
}
}
driver_add_attrs()向drv目錄下添加屬性,只是這些屬性都是在bus中定義的drv_attrs[]。
driver_remove_attrs()從drv目錄中刪除相應的bus->drv_attrs[]。
static int __must_check add_bind_files(struct device_driver *drv)
{
int ret;
ret = driver_create_file(drv, &driver_attr_unbind);
if (ret == 0) {
ret = driver_create_file(drv, &driver_attr_bind);
if (ret)
driver_remove_file(drv, &driver_attr_unbind);
}
return ret;
}
static void remove_bind_files(struct device_driver *drv)
{
driver_remove_file(drv, &driver_attr_bind);
driver_remove_file(drv, &driver_attr_unbind);
}
add_bind_files()在drv目錄下增加bind和unbind屬性。
remove_bind_files()從drv目錄下刪除bind和unbind屬性。
static ssize_t driver_uevent_store(struct device_driver *drv,
const char *buf, size_t count)
{
enum kobject_action action;
if (kobject_action_type(buf, count, &action) == 0)
kobject_uevent(&drv->p->kobj, action);
return count;
}
static DRIVER_ATTR(uevent, S_IWUSR, NULL, driver_uevent_store);
這是drv目錄下地uevent屬性文件,提供了從drv發送uevent的方法。
/**
* bus_add_driver - Add a driver to the bus.
* @drv: driver.
*/
int bus_add_driver(struct device_driver *drv)
{
struct bus_type *bus;
struct driver_private *priv;
int error = 0;
bus = bus_get(drv->bus);
if (!bus)
return -EINVAL;
pr_debug("bus: '%s': add driver %s\n", bus->name, drv->name);
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv) {
error = -ENOMEM;
goto out_put_bus;
}
klist_init(&priv->klist_devices, NULL, NULL);
priv->driver = drv;
drv->p = priv;
priv->kobj.kset = bus->p->drivers_kset;
error = kobject_init_and_add(&priv->kobj, &driver_ktype, NULL,
"%s", drv->name);
if (error)
goto out_unregister;
if (drv->bus->p->drivers_autoprobe) {
error = driver_attach(drv);
if (error)
goto out_unregister;
}
klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers);
module_add_driver(drv->owner, drv);
error = driver_create_file(drv, &driver_attr_uevent);
if (error) {
printk(KERN_ERR "%s: uevent attr (%s) failed\n",
__func__, drv->name);
}
error = driver_add_attrs(bus, drv);
if (error) {
/* How the hell do we get out of this pickle? Give up */
printk(KERN_ERR "%s: driver_add_attrs(%s) failed\n",
__func__, drv->name);
}
if (!drv->suppress_bind_attrs) {
error = add_bind_files(drv);
if (error) {
/* Ditto */
printk(KERN_ERR "%s: add_bind_files(%s) failed\n",
__func__, drv->name);
}
}
kobject_uevent(&priv->kobj, KOBJ_ADD);
return 0;
out_unregister:
kfree(drv->p);
drv->p = NULL;
kobject_put(&priv->kobj);
out_put_bus:
bus_put(bus);
return error;
}
bus_add_driver()看似是把drv與bus聯繫起來,其實是完成driver加入系統的大部分操作。
首先調用bus_get(drv->bus)增加對bus的引用。
分配並初始化drv->p,即driver_private結構。
調用kobject_init_and_add()將drv加入sysfs,之前只是設置了priv->obj.kset爲bus->p->drivers_kset,所以drv目錄會出現在bus目錄的drivers子目錄中。如果總線允許自動probe,就會調用driver_attach()將驅動和總線上的設備進行匹配,這個過程先略過。
然後調用klist_add_tail()將drv掛入總線的驅動鏈表。
調用module_add_driver()創建driver相關的模塊在sysfs中的表示。後面專門描述。
調用driver_create_file()在drv目錄下創建uevent屬性文件。
調用driver_add_attrs()在drv目錄下添加bus->driver_attrs[]中定義的屬性。
如果drv->suppress_bind_attrs爲零,即允許用戶空間決定驅動何時鏈接和卸載設備,則調用add_bind_files()添加bind和unbind屬性文件。
調用kobject_uevent()向用戶空間發佈KOBJ_ADD消息。
從bus_add_driver()的處理過程來看,driver只在bus的drivers目錄下出現,沒什麼軟鏈接,需要的屬性也不多。
/**
* bus_remove_driver - delete driver from bus's knowledge.
* @drv: driver.
*
* Detach the driver from the devices it controls, and remove
* it from its bus's list of drivers. Finally, we drop the reference
* to the bus we took in bus_add_driver().
*/
void bus_remove_driver(struct device_driver *drv)
{
if (!drv->bus)
return;
if (!drv->suppress_bind_attrs)
remove_bind_files(drv);
driver_remove_attrs(drv->bus, drv);
driver_remove_file(drv, &driver_attr_uevent);
klist_remove(&drv->p->knode_bus);
pr_debug("bus: '%s': remove driver %s\n", drv->bus->name, drv->name);
driver_detach(drv);
module_remove_driver(drv);
kobject_put(&drv->p->kobj);
bus_put(drv->bus);
}
bus_remove_driver()將drv從系統中撤銷,與bus_add_driver()相對應。
driver真正精彩的地方在於probe函數,對設備的操作,對用戶空間提供的接口,可惜這些都是特定的。這裏只能將driver與bus聯繫起來,並在以後與device聯繫起來。
不過不必失望,下面我們分析下drivers/base/module.c,它顯示了與驅動有關的module,在sysfs中的表現情況。
首先介紹使用到的結構。應該說module.c的代碼實現很簡單,但使用到的結構不簡單。
struct module_attribute {
struct attribute attr;
ssize_t (*show)(struct module_attribute *, struct module *, char *);
ssize_t (*store)(struct module_attribute *, struct module *,
const char *, size_t count);
void (*setup)(struct module *, const char *);
int (*test)(struct module *);
void (*free)(struct module *);
};
struct param_attribute
{
struct module_attribute mattr;
struct kernel_param *param;
};
struct module_param_attrs
{
unsigned int num;
struct attribute_group grp;
struct param_attribute attrs[0];
};
struct module_kobject
{
struct kobject kobj;
struct module *mod;
struct kobject *drivers_dir;
struct module_param_attrs *mp;
};
可以看到module_attribute結構除了包含struct attribute,還多增加了好幾條函數指針。而這只是最簡單的,struct param_attribute除了包含module_attribute,還有一個指向kernel_param的指針param。這個kernel_param就太複雜了,是外界向module提供參數用的窗口,這裏忽略。後面還有struct module_param_attrs和struct module_kobject。
static char *make_driver_name(struct device_driver *drv)
{
char *driver_name;
driver_name = kmalloc(strlen(drv->name) + strlen(drv->bus->name) + 2,
GFP_KERNEL);
if (!driver_name)
return NULL;
sprintf(driver_name, "%s:%s", drv->bus->name, drv->name);
return driver_name;
}
make_driver_name()將drv的名字和drv->bus的名字合起來,不過這是一個內部函數,具體使用還要看後面。
static void module_create_drivers_dir(struct module_kobject *mk)
{
if (!mk || mk->drivers_dir)
return;
mk->drivers_dir = kobject_create_and_add("drivers", &mk->kobj);
}
module_create_drivers_dir()在mk所在的目錄下創建一個drivers的目錄。不過因爲是使用kobject_create_and_add(),所以這個kobject使用默認的dynamic_kobj_ktype。
void module_add_driver(struct module *mod, struct device_driver *drv)
{
char *driver_name;
int no_warn;
struct module_kobject *mk = NULL;
if (!drv)
return;
if (mod)
mk = &mod->mkobj;
else if (drv->mod_name) {
struct kobject *mkobj;
/* Lookup built-in module entry in /sys/modules */
mkobj = kset_find_obj(module_kset, drv->mod_name);
if (mkobj) {
mk = container_of(mkobj, struct module_kobject, kobj);
/* remember our module structure */
drv->p->mkobj = mk;
/* kset_find_obj took a reference */
kobject_put(mkobj);
}
}
if (!mk)
return;
/* Don't check return codes; these calls are idempotent */
no_warn = sysfs_create_link(&drv->p->kobj, &mk->kobj, "module");
driver_name = make_driver_name(drv);
if (driver_name) {
module_create_drivers_dir(mk);
no_warn = sysfs_create_link(mk->drivers_dir, &drv->p->kobj,
driver_name);
kfree(driver_name);
}
}
module_add_drivers()在module下添加與driver的聯繫。
開始調用kset_find_obj()從module_kset下尋找drv所屬的module對應的kobj。說明每個module在加載時都會在/sys/module中創建一個kobject目錄。這裏找到後只是將其賦給drv->p->kmobj,並調用kobject_put()釋放找到時加上的引用計數。至於爲什麼driver不保留對module的引用計數,或許是不需要,或許是已經存在了。
接下來調用sysfs_create_link()在驅動目錄中添加指向module目錄的軟鏈接,名稱就是module。
調用module_create_drivers_dir()在module目錄下建立drivers子目錄。
調用sysfs_create_link()在drivers子目錄下建立指向驅動目錄的軟鏈接,名稱使用make_driver_name()的返回結果。
void module_remove_driver(struct device_driver *drv)
{
struct module_kobject *mk = NULL;
char *driver_name;
if (!drv)
return;
sysfs_remove_link(&drv->p->kobj, "module");
if (drv->owner)
mk = &drv->owner->mkobj;
else if (drv->p->mkobj)
mk = drv->p->mkobj;
if (mk && mk->drivers_dir) {
driver_name = make_driver_name(drv);
if (driver_name) {
sysfs_remove_link(mk->drivers_dir, driver_name);
kfree(driver_name);
}
}
}
module_remove_driver()消除driver與相應module之間的軟鏈接關係。
對於module,應該是另一個議題了,這裏只是簡單涉及,下節我們將涉及到總線bus,並深入分析device和driver的關係。