我的環境：
主機開發環境：Fedora14
開發板： TQ2440
編譯器： arm-linux-gcc-4.3.2
總線設備驅動模型其實現主要是基于Kobject和sysfs等機制，對于驅動模型程序開發主要是理解三個元素：總線、設備、驅動的關系。三者之間因為一定的聯系性實現對設備的控制。
首先是總線，總線是三者聯系起來的基礎，通過一種總線類型，將設備和驅動聯系起來。總線類型中的match函數用來匹配設備和驅動。當匹配操作晚餐之后就會控制驅動程序中的probe函數。
總線設備驅動模型的設計主要包括三個元素的注冊，將三個元素加載到內核中，然后通過內核的內部機制將三者聯系起來。
首先，總線類型的注冊，包括屬性文件的添加，總線也是一種設備，也需要將總線設備注冊。
其次，完成設備的注冊和添加以及對設備添加設備屬性文件，同時填充最基本的函數操作。
最后，完成驅動的注冊和天極以及對設備驅動添加屬性文件，同時填充最基本的函數操作。
1、總線
總線類型是通過結構體bus_type表示的。其源碼如下所示：
struct bus_type {
/*總線名*/
const char *name;
/*總線、設備、驅動屬性*/
struct bus_attribute *bus_attrs;
struct device_attribute *dev_attrs;
struct driver_attribute *drv_attrs;
/*總線支持的函數操作*/
/*匹配函數，主要用來識別相應的設備和驅動，是兩者直接形成關聯
用來判斷指定的驅動程序能否處理指定的設備
*/
int (*match)(struct device *dev, struct device_driver *drv);
/*在進行熱插拔事件之前，為設備配置環境變量操作函數*/
int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
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 (*suspend_late)(struct device *dev, pm_message_t state);
int (*resume_early)(struct device *dev);
int (*resume)(struct device *dev);
struct dev_pm_ops *pm;
struct bus_type_private *p;
};
其中的int (*match)(struct device * dev, struct device_driver * drv)是必須實現的函數，因為這個函數主要是實現設備和驅動之間的匹配管理。其中匹配的具體邏輯關系需要驅動設計著設定。
int (*uevent)(struct device *dev, char **envp, int num_envp,char *buffer, int buffer_size)則在熱插拔事件之前，允許總線為設備添加環境變量。
通常創建一種總線類型的過程中只要完成總線類型結構體的填充，然后完成相應的注冊、屬性文件創建即可實現總線類型的添加。并不需要對bus_type類型中的所有變量進行賦值，只要將其中的name,bus_attribute,match實現即可。
最后不要忘了總線也是設備，需要將總線設備添加到內核中（注冊函數）。
關于總線類型的屬性設置，實質上就是完成一個結構體的操作。
如下源碼所示：
struct bus_attribute {
/*屬性結構體*/
struct attribute attr;
/*屬性讀操作函數，即顯示函數*/
ssize_t (*show)(struct bus_type *bus, char *buf);
/*屬性寫操作函數，也就是存儲到結構體中*/
ssize_t (*store)(struct bus_type *bus, const char *buf, size_t count);
};
/*可以通過宏命令定義一個總線結構體，但是需要自己實現屬性讀寫操作函數，如果沒有，可設置為NULL*/
/*總線屬性定義宏*/
#define BUS_ATTR(_name, _mode, _show, _store) \
struct bus_attribute bus_attr_##_name = __ATTR(_name, _mode, _show, _store)
/*__ATTR的宏實現如下所示：*/
#define __ATTR(_name,_mode,_show,_store) { \
.attr = {.name = __stringify(_name), .mode = _mode }, \
.show = _show, \
.store = _store, \
}
由于通常情況下需要查找總線的版本信息，可以將版本信息添加到屬性的讀屬性操作函數中，這樣就能顯示具體的版本信息。
在宏定義中##是指鏈接符的作用，相當于將兩個部分鏈接起來，比如bus_attr_##name = bus_attr_name。這是在宏定義中比較常用的定義方式之一。
總線類型的注冊和總線類型屬性文件創建，以及總線設備的注冊主要是依據下面幾個函數來實現：
/*總線類型注冊函數，由于可能會出錯，因此必須對返回值進行檢查*/
int __must_check bus_register(struct bus_type *bus);
/*總線類型釋放函數*/
void bus_unregister(struct bus_type *bus);
/*總線文件屬性創建函數，將相關的文件屬性添加給總線類型，同時也必須檢查返回值是否正確*/
int __must_check bus_create_file(struct bus_type *,struct bus_attribute *);
/*總線類型文件屬性刪除函數，將兩者之間的關聯性切斷*/
void bus_remove_file(struct bus_type *, struct bus_attribute *);
最后需要將總線設備添加到系統中，主要采用設備注冊函數;
設備注冊函數：
int __must_check device_register(struct device *dev);
設備釋放函數：
void device_unregister(struct device *dev);
2、設備
設備的實現主要是依靠struct device函數實現的，設備的實現主要是對結構體的填充。實現相應的函數即可。
struct device {
/*父設備，通常就是總線設備，這也是為什么需要將總線作為設備添加的原因*/
struct device *parent;
struct device_private *p;
struct kobject kobj;
/*init_name是新添加的，替代了原來的bus_id,但是init_name不能直接被讀寫操作*/
const char *init_name; /* initial name of the device */
struct device_type *type;
struct semaphore sem; /* semaphore to synchronize calls to
* its driver.
*/
/*總線類型，主要是關聯總線類型，這是前面添加的總線類型，通過相同的總線類型關聯設備和驅動*/
struct bus_type *bus; /* type of bus device is on */
struct device_driver *driver; /* which driver has allocated this device */
void *driver_data; /* data private to the driver */
void *platform_data; /* Platform specific data, device
core doesn't touch it */
struct dev_pm_info power;
#ifdef CONFIG_NUMA
int numa_node; /* NUMA node this device is close to */
#endif
u64 *dma_mask; /* dma mask (if dma'able device) */
u64 coherent_dma_mask; /* Like dma_mask, but for
alloc_coherent mappings as
not all hardware supports
64 bit addresses for consistent
allocations such descriptors. */
struct device_dma_parameters *dma_parms;
struct list_head dma_pools; /* dma pools (if dma'ble) */
struct dma_coherent_mem *dma_mem; /* internal for coherent mem
override */
/* arch specific additions */
struct dev_archdata archdata;
dev_t devt; /* dev_t, creates the sysfs "dev" */
spinlock_t devres_lock;
struct list_head devres_head;
struct klist_node knode_class;
struct class *class;
struct attribute_group **groups; /* optional groups */
/*必須實現的release函數*/
void (*release)(struct device *dev);
};
/*由于init_name 不能直接讀寫，只能通過*dev_name來讀寫設備名*/
static inline const char *dev_name(const struct device *dev)
{
return kobject_name(&dev->kobj);
}
/*實現對設備名的設置*/
int dev_set_name(struct device *dev, const char *name, ...)
__attribute__((format(printf, 2, 3)));
/*設備文件屬性結構體，必須注意的改變點*/
struct device_attribute {
/*屬性值*/
struct attribute attr;
/*設備屬性讀函數，必須注意是三個參數，不再是兩個參數*/
ssize_t (*show)(struct device *dev, struct device_attribute *attr,char *buf);
/*設備屬性寫操作，必須注意是四個參數，不是三個參數*/
ssize_t (*store)(struct device *dev, struct device_attribute *attr,const char *buf, size_t count);
};
/*設備屬性宏定義，主要用來實現設備文件屬性*/
#define DEVICE_ATTR(_name, _mode, _show, _store) \
struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store)
/*創建設備文件屬性函數，必須檢查返回值*/
int __must_check device_create_file(struct device *device,struct device_attribute *entry);
/*刪除設備文件屬性函數*/
void device_remove_file(struct device *dev,struct device_attribute *attr);
/*設備注冊函數，必須檢查返回值*/
int __must_check device_register(struct device *dev);
/*設備釋放函數*/
void device_unregister(struct device *dev);
需要注意的是linux-2.6.30內核以前，沒有init_name元素，而是元素bus_id，這個主要是實現設備名的填充，但是linux-2.6.30內核之后的在struct device中init_name代替了bus_id,但是需要注意的是init_name不能直接被讀寫，當需要讀寫設備名時只能采用特定的函數實現:dev_name()，set_dev_name()。當直接讀寫init_name會導致內核錯誤，出現Unable to handle kernel NULL pointer dereference at virtual address 00000000的錯誤。
最后注意device_attribute中的show,store函數不同于其他類型（總線、驅動）的函數，device_attribute中的show和store函數中的參數數量多了一個。
3、驅動
驅動管理一定的設備，其中的關系主要是內核的內部機制實現的，但是實現的具體邏輯需要在bus_type中的match函數中具體設計。通常是一定的設備名和驅動名匹配，當然也可以有其他的邏輯，具體的只需要設計好bus_type中的match函數。
驅動是由驅動結構體實現的。具體如下所示：
/*驅動結構體*/
struct device_driver {
/*驅動名，通常用來匹配設備*/
const char *name;
/*關聯的總線類型，總線、設備、驅動關聯的總線類型*/
struct bus_type *bus;
struct module *owner;
const char *mod_name; /* used for built-in modules */
/*驅動中最應該實現的操作函數主要包括probe和remove函數*/
/*當匹配完成以后的，入口函數*/
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);
struct attribute_group **groups;
struct dev_pm_ops *pm;
struct driver_private *p;
};
/*驅動注冊函數，返回值必須檢測*/
int __must_check driver_register(struct device_driver *drv);
/*驅動釋放函數*/
void driver_unregister(struct device_driver *drv);
/*驅動屬性結構體*/
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)
/*驅動屬性文件創建函數，返回值必須檢測*/
int __must_check driver_create_file(struct device_driver *driver,struct driver_attribute *attr);
/*驅動屬性文件移除函數*/
void driver_remove_file(struct device_driver *driver,struct driver_attribute *attr);
驅動結構體的定義不需要完成所有元素的賦值，只需要完成主要的幾個變量的賦值即可，其中主要的元素包含name,bus,以及probe和remove函數的實現。
其中的probe函數是當總線中的match完成匹配操作以后，進入驅動的入口函數，因此必須實現。remove我認為就是對應的退出函數，因此也有必要實現。
驅動的注冊,釋放也有相關的函數來操作，主要是driver_register()和driver_unregister()。
總結：
1、在總線驅動模型中我認為最主要的是搞清楚三個不同的結構體，分別是總線、驅動、設備。了解三個元素對應的屬性結構體以及相應的屬性操作函數的差異性。
2、不同驅動設計的關鍵主要是完成不同結構體的填充過程，但是并不需要對結構體中所有的對象進行賦值，只需要完成重要的幾個元素的值。
3、總線是一種類型，同時也是一種設備，在總線的相關處理中需要首先添加總線類型，然后添加總線設備，這是需要注意的。由于總線類型關聯驅動和設備，因此需要導出總線類型變量。由于總線設備是設備的父設備，因此也需要將總線設備變量導出。同樣在驅動和設備中也要導出相關的結構體變量，便于總線中的match函數實現驅動和設備的匹配操作。
4、XXX_attr結構體基本相同，都是一個屬性結構體和函數show()、stroe()。但是不同的XXX可能會導致show、stroe函數的參數發生變化。這需要對照源碼。
5、struct device中的init_name是一個特殊的量，不能直接讀寫操作，只能采用函數device_name()和set_device_name來設置設備名。
6、xxx_register()之類的函數，需要對返回值進行檢查。因為很有可能不成功