精华内容
下载资源
问答
  • linux内核驱动模型

    2016-05-17 16:56:00
    linux内核驱动模型,以2.6.32内核为例。(一边写一边看的,有点乱。) 1、以内核对象为基础。用kobject表示,相当于其它对象的基类,是构建linux驱动模型的关键。具有相同类型的内核对象构成内核对象集,用kset...

    linux内核驱动模型,以2.6.32内核为例。(一边写一边看的,有点乱。)

     

    1、以内核对象为基础。用kobject表示,相当于其它对象的基类,是构建linux驱动模型的关键。
    具有相同类型的内核对象构成内核对象集,用kset表示,内核对象集也包含自己的内核对象,从而组成层次化的结构。
    2、用sysfs文件系统导出到用户空间。内核中的所有内核对象组织成树状,以对象属性为叶子。
    通过sysfs文件系统,将用户空间对文件的读写操作转化为对内核对象属性的显示和保存方法。从而导出内核对象信息,并提供配置接口。
    3、将linux子系统表达为总线类型、驱动、设备、类、接口的关系,分别用bus_type、device_driver、device、class、class_interface结构表示。
    每个子系统有自己的总线类型,它有一条驱动链表和一条设备链表,用来链接已加载的驱动和已发现的设备,驱动加载和设备发现的顺序可以是任意的。
    每个设备可以被绑定到最多一个驱动,被绑定了驱动的设备可以正常工作。
    除此之外,每个设备可以属于某个唯一的类,在类上包含多个接口,接口的方法被用于设备,不管是先添加接口,还是先发现设备。

    内核引用计数kref
    在程序动态运行的情况下,常常需要将一个内核分配好的对象多次传递和使用。为了在该对象不再被使用时回收其内存资源,需要对该对象的引用进行计数。
    kref有两个好处:防止内存泄露,在对象不被使用时释放内存;防止访问已释放的内存,确保不会访问已释放的对象。
    kref的操作
    kref_init():初始化对象为1,而不是0,因为生成该对象的代码也需要一个最初的引用,以防止其他部分在调用kref_put()时释放对象。
    kref_get():递增对象的引用计数。
    kref_put():递减对象的引用计数,如果计数为0,则调用传入的release方法。

    kset具有以下功能:
    作为包含一组对象的容器,kset可以被内核用来跟踪“所有块设备”或者“所有PCI设备驱动”。
    作为一个目录级的“粘合剂”,将设备模型中的内核对象(以及sysfs)黏在一起。每个kset都内嵌一个kobject,可以作为其他kobject的父亲,通过这种层次构造设备模型层次。
    kset可以支持kobject的“热插拔”,影响热插拔事件被报告给用户空间的方式。

    举个形象的例子:
    kset好比一个文件夹,kobject是文件夹下面的内容,kobject的类型可以不同,好比文件夹下有图片、视频、文档、程序等。
    不同的kset好比不同的文件夹,但它们下面可以有相同类型的kobject。比如文件夹A和B下面都有图片和视频。
    kset自身也有一个kobject,好比文件夹本质上也是一个文件一样,如同视频、图片之类的。
    通过kset的list能找到下面的kobject,即找到这个文件夹,就能找到该文件夹下面的内容。
    kobject的kset指向该kobject所属的kset,即文件夹下面的内容都属于这个文件夹之内。
    kset通过kobject的entery将kobject组织起来,类似于文件夹下面的文件的路径都是相同的。
    kobject的parent可以指向同kset下的另一个kobject,或者NULL,或者kset的kobject。


    1、创建或初始化内核对象:kobject_create()和kobject_init()。两者的区别是前者会为kobject分配存储空间,然后调用kobject_init(),而后者是用于初始化已经分配了内存的kobject()。
    2、将内核对象添加到sysfs:kobject_add()。该函数只会为默认属性自动创建sysfs文件。如果有其他属性,则需要另外创建sysfs文件。
    kobject的parent决定该kobject在sysfs树中的位置。
    1)若kobject的parent和kset都是空,则该kobject在sysfs树的根目录下。
    2)若kobject的parent是空,kset已设置,则该kobject在sysfs树的位置在kset的kobject目录下。
    3)若kobject的parent和kset都已设置,则该kobject在sysfs的位置在parent下。
    3、创建、初始化、添加内核对象集:
    kset_init()、kset_create()两者的区别和kobject_create()、kobject_init()的一样。
    kset_add():添加内核对象集到sysfs
    kset_register():kset_init()+kset_add()
    kset_create_and_add():等价于kset_create+()kset_add()
    4、发送内核对象变化事件到用户态空间
    kobject_uevent()->kobject_uevent_env()

    sysfs
    从两个角度理解:
    1、从内部看,sysfs是一种表示内核对象、对象属性,以及对象关系的一种机制。sysfs核心将内核输出的对象、对象属性以及对象关系组织成树状结构,称为sysfs内部树。
    2、从外部看,sysfs类似于proc文件系统,用于将系统中的设备组织成层次结构(sysfs外部树),向用户空间导出设备和驱动信息,并且为设备和驱动提供配置接口。
    sysfs核心负责建立内部树和外部树的对应关系,也称为sysfs映射。
    1)内核对象被映射为用户空间的目录
    2)对象属性被映射为用户空间的常规文件
    3)对象关系被映射为用户空间的符号链接
    对sysfs的读写转换成对属性的show和store操作。

    总线类型
    结构体:bus_type、bus_type_private
    操作:bus_register()、bus_unregister()、bus_for_each_dev()、bus_for_each_drv()

    设备
    结构体:device、device_private
    操作:device_register()、device_unregister()

    驱动
    结构体:device_driver、driver_private
    操作:driver_register()、driver_unregister()


    结构体:class、class_private
    操作:class_register()、class_unregister()

    接口
    结构体:class_interface
    操作:class_interface_register()、class_interface_unregister()


    普通双向链表
    struct foo {
    struct foo * prev;
    struct foo * next;
    int val;
    };
    prev/next是类型相关的,都是struct foo *型。如果要在另外一个struct foo1中使用链表,必须重新定义foo1私有的链表。
    struct foo1 {
    struct foo1 * prev;
    struct foo1 * next;
    int val;
    char c;
    };
    foo和foo1的链表操作,本质上虽然相同,但由于两者类型不同,所以不同通用。
    比如插入,foo的插入,操作的是struct foo *型;而foo1的插入,操作的是stcut foo1 *型。

    内核链表
    struct list_head {
    struct list_head * prev;
    struct list_head * next;
    };
    struct foo {
    struct list_head list;
    int val;
    };
    prev/next是类型无关的,都是struct list_head*型,和所在结构体无关。如果要在另一个结构体foo1中使用链表,只需在foo1中包含该成员即可。
    struct foo1 {
    struct list_head list;
    int val;
    char c;
    };
    链表的操作可以通用,都是操作struct list_head *型。

    bus_register()

     

    转载于:https://www.cnblogs.com/maoxiaowai/p/5502333.html

    展开全文
  • Linux 内核驱动模型

    2012-01-02 00:43:39
    #include #include #include MODULE_LICENSE("GPL"); ... //很简单啊,这是设备驱动的最简单的模型。 int test(void) { printk("HELLO KERNEL\n"); } void test_exit(void) { printk("--
    #include <linux/init.h>
    #include <linux/module.h>
    
    #include <asm/thread_info.h>
    
    MODULE_LICENSE("GPL");
    MODULE_AUTHOR("DINGL"); //很简单啊,这是设备驱动的最简单的模型。
    
    int test(void)
    {
             printk("HELLO KERNEL\n");
    }
    
     void test_exit(void)
    {
             printk("-- exit ----\n");
    }
    
    module_init(test);
    module_exit(test_exit);
    代码不解释
    展开全文
  • 若你发现有需要改正的地方欢迎指出本文与原文档采用相同许可协议发布综述Linux内核驱动模型是一种以前在用的所有模型的统一。它目的在于通过增加一组数据和方法到全局的数据结构上为桥和设备增加总线驱动。...
    翻译自Linux Kernel的文档,Documentation/driver-model/overview.txt
    该翻译源于译者个人兴趣,其中某些地方可能含糊不清、歧义、甚至错误,请参考原始文档阅读文。
    若你发现有需要改正的地方欢迎指出
    本文与原文档采用相同许可协议发布


    综述


    Linux内核驱动模型是一种以前在用的所有模型的统一。它目的在于通过增加一组数据和
    方法到全局的数据结构上为桥和设备增加总线驱动。

    传统的驱动模型为他们要控制的设备实现了一个有序的类树结构(有时只是一个链表),
    在不同的总线类型间他们并不是统一的。

    现在的驱动模型提供了一个公共的、统一的数据模型来描述总线和可被总线发现的设备。
    统一的总线模型包含了一组公共的属性和一组公共的回调,用来总线发现,总线关闭,
    总线电源管理等等。

    设备与桥接口反应了现代计算机的目标:也就是“即插即用”的能力,可电源管理,可热插拔。
    特别的,这个模型被Intel和Microsoft使用(即ACPI),确保每个设备几乎都挂在总线上,
    x86兼容系统则可在这个范式下运行。当然,不是所有总线都完全支持以这些操作,但是大
    部分总线是支持大部分的这些操作。


    下游开发


    公共的数据成员已经从单独的总线层移动到公共的数据结构中了。这些成员必须总是能够
    被总线层访问,有时需要被特定设备驱动访问。

    其它总线驱动层最好是像PCI总线驱动层做的那样
    struct pci_dev 现在大概长这个样子:

    struct pci_dev {
        ...

        struct device dev;     /* Generic device interface */
        ...
    };

    首先要注意的是struct device dev在struct pci_dev中是被静态申请的。意思是在
    设备发现的过程中,说只为设备申请一次内存。

    然后要注意的是struct device dev并不必被定义在pci_dev结构体的头部。这是为了
    使开发者思考在切换总线驱动和全局驱动时他们做了什么,并且阻止他们在这两者之
    间做没有意义和不正确的转换。

    PCI总线驱动层自由地访问struct device的成员,这是因为它知道这个结构体在
    struct pci_dev中。通常单独的PCI设备驱动已经被转换到当前驱动模型下了,不要去动
    struct device下的成员,除非有什么迫不得已的理由需要这么做。

    以上说明防止你在过渡期间不必要的痛苦。如果不这样做,那么所有的数据成员将会被
    重命名或者被移除,所有的下游驱动都会坏掉。另一方面,如果只是总线层(不是设备层)
    访问struct device,那么仅仅只是总线层需要被修改。


    用户接口


    通过系统中所有设备的完全分层的结构所带来的优点,内核将完全分层的结构导出到
    用户空间变得相对简单。这些的实现是通过一个名为sysfs的虚拟文件系统来完成的。

    几乎所有的主流Linux发行版会自动挂载这个文件系统;你可以输入“mount”命令来看到
    类似于以下内容的输出

    $ mount
    ...
    none on /sys type sysfs (rw,noexec,nosuid,nodev)
    ...
    $

    自动挂载sysfs文件系统通常是通过/etc/fstab文件中的一条记录实现的,大概如下所示

    none         /sys    sysfs    defaults          0 0

    或者在基于debian的系统中,在/lib/init/fstab下有着类似于以下内容的记录

    none            /sys    sysfs    nodev,noexec,nosuid    0 0

    如果sysfs没有被自动挂载,你可以通过以下命令手动挂载

    # mount -t sysfs sysfs /sys

    每当设备被加入到设备树上时,sysfs中会为它创建一个目录。这个目录可以会出现在以下
    每个层的目录中 —— 全局层、总线层、设备层。

    全局层目前创建两个文件 - ‘name’ 和 ‘power’。前者只报告这个设备的名字,后者报告
    该设备当前的电源状态。它通常被用来设置设备当前的电源状态

    总线层在探测总线时可能也会为设备创建一些文件,比如说 PCI层会为每个设备都创建
    ‘irq’和‘resource’文件

    一个特定设备驱动在设备自己的目录瞎导出一些与设备相关的数据文件或者操作接口

    更多与sysfs目录相关的信息在在当前目录下别的文档中,还有Documentation/filesystems/sysfs.txt
    展开全文
  • 内核驱动模型何为驱动模型Linux驱动模型驱动模型dev类型 何为驱动模型 在我看来模型就是对一系列事务,进行抽象、统一、管理。所呈现出的一种层次关系。就像一个公司有部门、小组、个人这样的一个组织关系。那么这样...

    何为驱动模型

    在我看来模型就是对一系列事务,进行抽象、统一、管理。所呈现出的一种层次关系。就像一个公司有部门、小组、个人这样的一个组织关系。那么这样做的好处就是便于管理。

    Linux驱动模型

    在Linux的世界里将C语言运用到极致,在这里,不能单单的想象成结构体,要体会其数据结构背后的含义,而不能单单的理解成结构体类型。在c++中有个更好的说法叫类。所有的类型都想象成类更好理解。其中结构体的成员变量类比成属性,其中函数指针类比这个类所具有的方法。类比一个人物的固有血条(属性)以及这个人物的攻击技能(方法)。这样的结构在Linux里面很常见。

    驱动模型

    在Linux中最常见的驱动模型,就是设备(dev)-总线(bus)-驱动(drv),这样的模型结构。在Linux中类一般都是事务的抽象,提取一些通用的共同的内容。设备类型更多的是来描述这个设备具体的一些通用属性。bus是dev和drv的桥梁,纽带。dev和drv的关系就是靠bus来衔接。drv描述更多的方法,这一类的设备他具有哪些技能,一般在drv中进行描述。

    dev bus drv的类型定义在kernel\include\linux\device.h文件中

    dev类型—struct device

    在Linux中设备是一个宽泛的概念,并不是指某一个实体设备。是一个抽象出来的设备,不要当一个实体设备看待。

    struct device {
     struct device  *parent;
     struct device_private *p;
     struct kobject kobj;
     struct bus_type *bus;  /* type of bus device is on */
     struct device_driver *driver; /* which driver has allocated this
            device */
     void  *platform_data; /* Platform specific data, device
            core doesn't touch it */
     void  *driver_data; /* Driver data, set and get with
            dev_set/get_drvdata */
            ....
    }
    struct device_private {
     struct klist klist_children;
     struct klist_node knode_parent;
     struct klist_node knode_driver;
     struct klist_node knode_bus;
     struct list_head deferred_probe;
     struct device *device;
    };
    
    1. 其中最重要的几个成员变量是*bus *driver指针,指向和这个dev相关联的总线和驱动。
    2. 同时还有这个*p的成员变量。这个list node届时就会插入到bus管理的那个dev链表中去,被管理起来,还有drv的节点也会插入到drv管理的dev链表中去,被drv管理起来。
    3. 而根据这个结构体,我就能知道自己这个设备是属于哪个bus,以及知道我的驱动是哪个。
    4. dev的name存在于kobj的成员变量name中,他两用同一个name。

    bus类型—struct bus_type

    这里的bus,同样是宽泛的概念,并不是cpu中实实在在的总线,是一种程序上虚拟出的一种代码结构。

    struct bus_type {
     const char  *name;
     const char  *dev_name;
     struct device  *dev_root;
     struct subsys_private *p;
     int (*match)(struct device *dev, struct device_driver *drv);
     int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
     int (*probe)(struct device *dev);
     }
     
     struct subsys_private {
     struct klist klist_devices;
     struct klist klist_drivers;
     struct bus_type *bus;
     }
     
    
    1. match方法为这个bus中dev和drv他们两个匹配的方法,入参刚好一个是dev一个是drv,只有他们俩某个属性对上了(通常我们用dev和drv的名字作为匹配的条件),那么我们称这个dev和drv匹配上了然后就会去执行probe的方法,后面代码中会介绍。
    2. bus类型最重要的是*p这个成员变量。他管理了2个链表,分别是dev链表和drv链表。这样bus就起到一个管理者的角色。他就知道他当前的这个bus拥有哪些设备和驱动。

    drv类型—struct device_driver

    drv同样也是广泛意义上的驱动,并不是某一个具体外设的驱动。这里同样抽象出来了,但是具体的外设驱动肯定是基于这个数据结构的。有点像c++中外设驱动的父类那种感觉。

     struct device_driver {
     const char  *name;
     struct bus_type  *bus;
     struct driver_private *p;
     int (*probe) (struct device *dev);
     }
     
     struct driver_private {
     struct kobject kobj;
     struct klist klist_devices;
     struct klist_node knode_bus;
     struct module_kobject *mkobj;
     struct device_driver *driver;
    };
    
    1. 根据*bus 知道我这个驱动是属于哪个bus的。
    2. 同样有个p,p里面有一个bus的节点,届时会插入到bus的那个p的drv链表下,被管理起来
    3. 除此之外还有一个dev的链表,而这个链表是用来管理这个驱动所匹配上所有的设备的,为什么有这样的结构,是应为一个设备只能有一个驱动,而一个驱动可以拥有好几个设备。多个相同或者类似的设备共享一个驱动。这个应该好理解。

    关系图

    在这里插入图片描述

    驱动中涉及的接口

    每个注册的接口都有一个register,同样和他相对应的有一个unregister接口,比如int driver_register(struct device_driver *drv) 与他对应有一个void driver_unregister(struct device_driver *drv)接口。主要用于资源的释放等相关操作。

    bus相关

    因为drv和dev的初始化都要涉及到bus,所以,在linux中bus都要先做初始化才能被dev和drv注册时使用。
    接口定义在\drivers\base\bus.c
    int bus_register(struct bus_type *bus)

    int bus_register(struct bus_type *bus)
    {
     int retval;
     struct subsys_private *priv;
     priv = kzalloc(sizeof(struct subsys_private), GFP_KERNEL); //申请bus的p空间
     priv->bus = bus;//p的bus指向这个将要注册的bus
     bus->p = priv;//将要注册的bus的p指向这个刚申请出来的p空间
     /* 初始化bus中p带的两个链表,分别是dev链表和drv链表 */
     klist_init(&priv->klist_devices, klist_devices_get, klist_devices_put);
     klist_init(&priv->klist_drivers, NULL, NULL);
     }
    

    dev相关

    接口定义在\drivers\base\core.c,实体大部分工作其实是device_add完成的。
    下面介绍的dev注册过程,是指bus上已经注册好drv的情况下,dev注册函数的调用过程,
    假如bus上没有drv,那么调用过程没有这么复杂。
    假如bus没有匹配的drv说明当前dev的驱动没有或者还没有注册上,没关系,等drv注册的时候还是会来扫一遍设备然后在执行bus的probe方法。
    int device_register(struct device *dev)—》int device_add(struct device *dev)

    int device_add(struct device *dev)
    {
    if (dev->init_name) {//用init_name 来初始化这个dev的名字
      dev_set_name(dev, "%s", dev->init_name);
      dev->init_name = NULL;
     }
     //一系列检查无误后最后调用bus_add_device->\
     //                klist_add_tail(&dev->p->knode_bus, &bus->p->klist_devices);
     //把这个dev成员p的bus节点插入到-》bus成员p的dev链表上去,被bus管理起来。
     error = bus_add_device(dev);
      bus_probe_device(dev);
    }
    //调用过程简化
    bus_probe_device(dev)-device_initial_probe(dev)-__device_attach(dev, true)\
    	-》ret = bus_for_each_drv(dev->bus, NULL, &data,__device_attach_driver)\
    	-int __device_attach_driver;
    //重要函数--循环取bus上的drv链表上的驱动来挨个和这个注册的dev尝试匹配是否能匹配上。\
    //而尝试匹配函数即为fn---也就是-》__device_attach_driver
    int bus_for_each_drv(struct bus_type *bus, struct device_driver *start,
           void *data, int (*fn)(struct device_driver *, void *))
    {
      while ((drv = next_driver(&i)) && !error)
      error = fn(drv, data);
    }
    __device_attach_driver(struct device_driver *drv, void *_data)
    {
    //直接调用bus的match接口,所以是否匹配成功的条件是,bus在注册的时候match方法决定的。\
    //-》drv->bus->match(dev, drv)
     ret = driver_match_device(drv, dev);
     if (ret == 0) {
      /* no match */
      return 0;
     }
     return driver_probe_device(drv, dev);
    }
    
    driver_probe_device(drv, dev);-really_probe(dev, drv);
    
    really_probe(struct device *dev, struct device_driver *drv)
    {
     dev->driver = drv;
     if (dev->bus->probe) {
      ret = dev->bus->probe(dev);
     }
     else if (drv->probe) {
      ret = drv->probe(dev);
     }
     //绑定驱动,dev的p拥有的drv节点插入到drv的成员变量p的dev链表中,被drv管理起来。
     //最后实现klist_add_tail(&dev->p->knode_driver, &dev->driver->p->klist_devices);
     driver_bound(dev);
    }
    

    drv相关

    同样下面drv的注册也是基于bus上面dev已有的情况下进行分析。drv注册函数大部分工作在bus_add_driver完成。
    接口定义在\drivers\base\driver.c
    int driver_register(struct device_driver *drv)-》bus_add_driver(drv);

    int bus_add_driver(struct device_driver *drv)
    {
     struct bus_type *bus;
     struct driver_private *priv;
     priv = kzalloc(sizeof(*priv), GFP_KERNEL);//申请drv结构的成员变量p
     //初始化p的dev链表,届时dev注册的时候,会吧dev挂载这个链表下面,被drv所管理起来。
     klist_init(&priv->klist_devices, NULL, NULL);
     priv->driver = drv;//p的drv指针指向这个drv
     drv->p = priv;//drv的p指向这块申请的内存,
     //上面这两个操作意思就是随便拿到p还是drv都能拿到对方的结构。
    //把drv的p成员的bus节点,插到bus成员p的drv链表上,被bus管理起来,操作和dev的注册类似。
     klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers);
     error = driver_attach(drv);
    }
    
    driver_attach-bus_for_each_dev(drv->bus, NULL, drv, __driver_attach);
    int __driver_attach(struct device *dev, void *data)
    {
    //这个函数在dev注册的时候也出现过,调用bus的match接口用来判断这个dev和drv是否匹配。
     ret = driver_match_device(drv, dev);
     if (ret == 0) {
      /* no match */
      return 0;
     }
     if (!dev->driver)
     //这个函数同样在dev注册的时候也出现过,其作用,判断bus的probe假如有则调用,、
     //否则在指向drv的probe,同时要把这个dev绑定到这个驱动上去,被这个驱动管理起来。
      driver_probe_device(drv, dev);
      
    }
    

    bus_for_each_dev和drv注册的时候类似,取bus上的每一个dev和你这个驱动进行匹配。匹配的方法为 __driver_attach

    总结

    总的来说Linux中的代码确实很多,全部看懂实在不大可能,包括这篇文章中我也是删减了很多和主题不大相关的代码和内容。比如代码中有很多和调试相关和文件系统相关的内容我都没要贴,因为这些内容主要是在/sys/class/目录下的一些层次关系的管理,和本文的主题没什么太大的关联,所以看代码也一样,不是太相关的就直接略过,毕竟经历有限。而如何判断哪些是相关的,哪些是次要的,那就要好好的积累经验了,万事都有一个过程,你慢慢的熟悉了,接触的多了,就会有意识。

    后续

    当初学习的时候也会去网上查资料,先看别人的理解,摸摸大体主干,然后自己再去看代码,验证是否理解正确。看了很多资料后,理论架构说的很清楚了,但心里还是有一个疑问,这套东西,用在什么地方,有什么好。说白了就是缺少理论和实际的结合。所以我后面还会在写一篇,介绍这个驱动模型的实例平台总线的运用。理论和实例的结合分析会让你更好的理解这个知识点。

    展开全文
  • 翻译自Linux Kernel的文档,Documentation/driver-model/binding.txt该翻译源于译者个人兴趣,其中某些地方可能含糊不清、歧义、甚至错误,请参考原始文档阅读文。若你发现有需要改正的地方欢迎指出本文与原文档采用...
  • 杂项设备模型基本介绍 设备号: 主设备号:固定是 10 次设备号: 0~255, 当传递 255 时候表示自动分配次设备号 安装后,可以自动创建/dev/设备文件节点。 注册函数: int misc_register(struct miscdevice * ...
  • 上来就有两句话没看懂:在2.4版本的内核中,每一个设备的物理部分都由一段总线特定的代码来控制。总线代码负责各种不同类型的任务,而每一种具体总线的代码之间则没有交互。后一句的原文是:This bus code was ...
  • Linux设备驱动模型:1. struct bus_type 的对象来表示一个总线 struct device 的对象来表示一个挂在总线上的设备 struct device_driver 对象来表示一个挂在总线上的设备驱动总线: 一个总线可以挂多个设备和多个...
  • 和misc杂项设备以及早期经典设备模型比较,有如下的特征: 1. 安装后, 不会自动创建/dev/设备文件节点, 需要手动使用 mknod 命令创建。可以使用设备类的方法自动创建设备节点。 2. 调用一个 cdev_add 注册后, ...
  • Linux内核设备模型与总线 - 内核版本 Linux Kernel 2.6.34, 与 Robert.Love的《Linux Kernel Development》(第三版)所讲述的内核版本一样 - 源代码下载路径: ...
  • Linux platform设备驱动模型 文章目录Linux platform设备驱动模型前言框架设备与驱动的分离设备(device)驱动(driver)匹配(match)参考 前言 为什么要往平台设备驱动迁移?这里需要引入设备,总线,驱动这三个...
  • 如果你了解了前面总线、设备模型,分析总线设备驱动模型的driver相对来说会轻松很多。开始也是看看其数据结构。 struct device_driver { const char *name; /*驱动的名字*/ struct bus_type *bus; /*驱动属于...
  • 之前我们分析了引用计数kref,总结了sysfs提供的API,并翻译了介绍...一是因为kobject的代码很重要,会在设备驱动模型代码中无数次被用到,如果不熟悉的话可以说是举步维艰。二是为了熟悉linux的编码风格,为以后分析
  • linux内核之设备驱动模型前言一、设备模型的基石---kobject子系统二、设备模型的总框架---总线、设备和驱动模型三、有关驱动的虚拟内存文件系统---Sysfs系统 前言 七七八八,磨磨蹭蹭,终于大体上是把LDD3弄完了(大...
  • linux从2.6开始就加入了一套新的驱动管理和注册机制平台总线,是一条虚拟的总线,设备用platform_device表示,驱动用platform_driver进行注册。于传统的总线/设备/驱动程序机制相比,平台由内核进行统一管理,在驱动...
  • Linux内核设备模型(1)

    千次阅读 2009-12-01 20:41:00
    Linux内核设备模型翻译者:郭少悲2009/12/01原文:linux/Documentation/driver-model/overview.txt概述~~~~Linux内核驱动模型是针对内核之前所有不同的驱动模型的统一抽象模型。它的目的是,通过结合一套数据和操作集...
  • 最近学习了linux系统的总线驱动模型,在这就简单的讲一下自己对于其中的理解 在这个驱动模型中由几个重要的概念 : 总线 :这个"总线"不是我们通常所说的传输数据的总线,而是将设备和驱动联系起来的一个中间件,...
  • linux驱动内核模型

    千次阅读 2009-12-10 16:36:00
    内核驱动模型的初衷2.6内核增加了一个引人注目的新特性——统一设备模型(devicemodel)。设备模型提供了一个独立的机制专门来表示设备,并描述其在系统中的拓扑结构,从而使得系统具有以下优点:l 代码重复最小化。l...
  • linux的设备驱动模型,是建立在sysfs和kobject之上的,由总线、设备、驱动、类所组成的关系结构。从本节开始,我们将对linux这一设备驱动模型进行深入分析。  头文件是include/linux/device.h,实现在drivers/...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,093
精华内容 837
关键字:

linux内核驱动模型

linux 订阅