转 Linux设备模型 (1)

作者:wwang 
出处:http://www.cnblogs.com/wwang 
本文采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接。

随着计算机的周边外设越来越丰富,设备管理已经成为现代操作系统的一项重要任务,这对于Linux来说也是同样的情况。每次Linux内核新版本的发布,都会伴随着一批设备驱动进入内核。在Linux内核里,驱动程序的代码量占有了相当大的比重。下图是我在网络上搜索到的一幅Linux内核代码量的统计图,对应的内核版本是2.6.29。

我们可以很明显的看到,在Linux内核中驱动程序的比例已经非常高了。

Linux 2.6内核最初为了应付电源管理的需要,提出了一个设备模型来管理所有的设备。在物理上,外设之间是有一种层次关系的,比如把一个U盘插到笔记本上,实际上这个U盘是接在一个USB Hub上,USB Hub又是接在USB 2.0 Host Controller (EHCI)上,最终EHCI又是一个挂在PCI Bus上的设备。这里的一个层次关系是:PCI->EHCI->USB Hub->USB Disk。如果操作系统要进入休眠状态,首先要逐层通知所有的外设进入休眠模式,然后整个系统才可以休眠。因此,需要有一个树状的结构可以把所有的外设组织起来。这就是最初建立Linux设备模型的目的。

当然,Linux设备模型给我们带来的便利远不止如此。既然已经建立了一个组织所有设备和驱动的树状结构,用户就可以通过这棵树去遍历所有的设备,建立设备和驱动程序之间的联系,根据类型不同也可以对设备进行归类,这样就可以更清晰的去“看”这颗枝繁叶茂的大树。另外,Linux驱动模型把很多设备共有的一些操作抽象出来,大大减少了重复造轮子的可能。同时Linux设备模型提供了一些辅助的机制,比如引用计数,让开发者可以安全高效的开发驱动程序。达成了以上这些好处之后,我们还得到了一个非常方便的副产品,这就是sysfs----一个虚拟的文件系统。sysfs给用户提供了一个从用户空间去访问内核设备的方法,它在Linux里的路径是/sys。这个目录并不是存储在硬盘上的真实的文件系统,只有在系统启动之后才会建起来。

下面这个命令可以用来显示sysfs的大致结构:

tree /sys

这个命令的信息量非常大,我就不贴出来了,如果有兴趣的话可以看看这里,或者自己动手实验一下。

我们来看看第一层目录结构:

/sys
|-- block
|-- bus
|-- class
|-- dev
|-- devices
|-- firmware
|-- fs
|-- kernel
|-- module
`-- power

这里有10个子目录,但并不是说这10个目录代表了10种完全不同的设备类型,实际上这些目录只是给我们提供了如何去看整个设备模型的不同的视角。其实从不同的目录出发都有可能找到同一个设备的。那真正的设备信息到底放在哪里呢?看看目录的名称就应该能猜到,对,就是devices子目录,Linux的所有设备都可以在这个目录里找到。这里是一个大杂烩,虽然五脏俱全但我们却无从下手。这里还是以U盘为例,插上U盘之后,在devices目录里如何找到这支U盘呢?真得很难办到。但是如果知道这个U盘在系统里的设备文件名(暂且假设为sdb),那就可以从block目录着手。

透过block目录,我们很容易就可以找到这个U盘设备,符号链接device正是指向devices目录下的位置。

到这里,我们总结一下/sys目录下各个子目录的作用。block目录是从块设备的角度来组织设备;bus目录是从系统总线这个角度来组织设备,比如PCI总线或者USB总线;class目录把看问题的视角提高到了类别的高度,比如PCI设备或者USB设备等;dev目录的视角是设备节点;devices目录在前面提到了,这里是所有设备的大本营;firmware目录包含了一些比较低阶的子系统,比如ACPI、EFI等;fs目录里看到的是系统支持的所有文件系统;kernel目录下包含的是一些内核的配置选项;modules目录下包含的是所有内核模块的信息,内核模块实际上和设备之间是有对应关系的,通过这个目录顺藤摸瓜找到devices或者反过来都是可以做到的;power目录存放的是系统电源管理的数据,用户可以通过它来查询目前的电源状态,甚至可以直接“命令”系统进入休眠等省电模式。

sysfs正是用户和内核设备模型之间的一座桥梁,通过这个桥梁我们可以从内核中读取信息,也可以向内核里写入信息。

在Linux里也可以找到一些图形化的工具来查询设备信息。比如GNOME下基于HAL的Device Manager:

或者KDE下基于Solid的KInfoCenter:

这些图形化的工具提供了更加直观的方式来访问设备,但是它们的提供的信息还不够全面,而且没有向内核设备写数据的功能。

如果具体到某一类型的设备,Linux下还有一些专用的工具可以使用。比如面向PCI设备的pciutils,面向USB设备的usbutils,以及面向SCSI设备的lsscsi等。对于Linux开发者来说,有时使用这些专用的工具更加方便。

我们如果要写程序来访问sysfs,可以像读写普通文件一样来操作/sys目录下的文件,或者,也可以使用libsysfs。不过需要注意的是,Linux内核社区并不推荐用libsysfs,因为这个API的更新不够快,赶不上内核的变化。libsysfs已经逐渐背离最初创建它的目标,这个lib带来的问题似乎比它解决的还要多。当然,如果只是要访问设备,一般很少会直接操作sysfs,它太细节太底层了,大部分情况下可以使用更加方便的DeviceKit或者libudev

总结一下,本文主要简单介绍了Linux设备模型的基本概念和虚拟文件系统sysfs。接下来的篇章里将和大家继续探讨设备模型在内核空间的一些细节。

时间: 2024-12-16 03:02:07

转 Linux设备模型 (1)的相关文章

【linux设备模型】之platform设备驱动

一.platform总线.设备和驱动 platform是一种虚拟总线,对应的设备称为platform_device,对应的驱动称为platform_driver. platform_device定义在<linux/platform_device.h>中: 1 struct platform_device { 2 const char * name; 3 int id; 4 struct device dev; 5 u32 num_resources; 6 struct resource * r

Linux设备模型——设备驱动模型和sysfs文件系统解读

本文将对Linux系统中的sysfs进行简单的分析,要分析sysfs就必须分析内核的driver-model(驱动模型),两者是紧密联系的.在分析过程中,本文将以platform总线和spi主控制器的platform驱动为例来进行讲解.其实,platform机制是基于driver-model的,通过本文,也会对platform机制有个简单的了解. 内核版本:2.6.30 1. What is sysfs? 个人理解:sysfs向用户空间展示了驱动设备的层次结构.我们都知道设备和对应的驱动都是由内

转 linux设备模型(4)

作者:wwang 出处:http://www.cnblogs.com/wwang 本文采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接. <Linux设备模型 (2)>和<Linux设备模型 (3)>主要通过一些简单的实作介绍了kobject.kset.kobj_type.attribute等数据结构的用法,但这些实作并没有涉及到实际环境下的设备模型和sysfs.本文将以/sy

linux设备模型之led子系统(转载)

linux设备模型之led子系统 本文来自转载: http://www.cnblogs.com/gdt-a20 时代不同了,连led都成子系统了,针对内核提供的通用模型,分析一下,好久没写文章了也! 代码位于drivers/leds下,看一下Makefile 模型文件主要是: # LED Core obj-$(CONFIG_NEW_LEDS)            += led-core.o obj-$(CONFIG_LEDS_CLASS)        += led-class.o obj-$

linux设备模型

为了降低设备多样性带来的Linux驱动开发的复杂度,以及设备热拔插处理.电源管理等,Linux内核提出了设备模型(也称作Driver Model)的概念.设备模型将硬件设备归纳.分类,然后抽象出一套标准的数据结构和接口.驱动的开发,就简化为对内核所规定的数据结构的填充和实现. 我们知道linux内核中常见的的总线有I2C总线,PCI总线,串口总线,SPI总线,PCI总线,CAN总线,单总线等,所以有些设备和驱动就可以挂在这些总线上,然后通过总线上的match进行设备和驱动的匹配.但是有的设备并不

linux设备模型之kobject

kobject 结构 在Linux内核里,kobject是组成Linux设备模型的基础,一个kobject对应sysfs里的 一个目录.从面向对象的角度来说,kobject可以看作是所有设备对象的基类,因为C 语言并没有面向对象的语法,所以一般是把kobject内嵌到其他结构体里来实现类似的 作用,这里的其他结构体可以看作是kobject的派生类.Kobject为Linux设备模型提 供了很多有用的功能,比如引用计数,接口抽象,父子关系等等.引用计数本质上就 是利用kref实现的. 另外,Lin

Linux 设备模型基本概念

1.设备模型引入 Linux 2.6内核最初为了应付电源管理的需要,提出了一个设备模型来管理所有的设备.在物理上,外设之间是有一种层次关系的,比如把一个U盘插到笔记本上,实际上这个U盘是接在一个USB Hub上,USB Hub又是接在USB 2.0 Host Controller (EHCI)上,最终EHCI又是一个挂在PCI Bus上的设备.这里的一个层次关系是:PCI->EHCI->USB Hub->USB Disk.如果操作系统要进入休眠状态,首先要逐层通知所有的外设进入休眠模式,

Linux 设备模型之 (kobject、kset 和 Subsystem)(二)

问题描写叙述:前文我们知道了/sys是包括内核和驱动的实施信息的,用户能够通过 /sys 这个接口.用户通过这个接口能够一览内核设备的全貌.本文将从Linux内核的角度来看一看这个设备模型是怎样构建的. 1.kobject 结构 在Linux内核里,kobject是组成Linux设备模型的基础,一个kobject相应sysfs里的一个文件夹. 从面向对象的角度来说.kobject能够看作是全部设备对象的基类,由于C语言并没有面向对象的语法,所以通常是把kobject内嵌到其它结构体里来实现类似的

Linux 设备模型之 kobject 内嵌结构

问题描述:前文我们知道了/sys是包含内核和驱动的实施信息的,用户可以通过 /sys 这个接口,用户通过这个接口可以一览内核设备的全貌.本文将从Linux内核的角度来看一看这个设备模型是如何构建的. 1.kobject 结构 在Linux内核里,kobject是组成Linux设备模型的基础,一个kobject对应sysfs里的一个目录.从面向对象的角度来说,kobject可以看作是所有设备对象的基类,因为C语言并没有面向对象的语法,所以一般是把kobject内嵌到其他结构体里来实现类似的作用,这