最新推荐文章于 2023-12-13 21:02:33 发布

初_xue_者

最新推荐文章于 2023-12-13 21:02:33 发布

阅读量1.2k

点赞数 1

分类专栏： linux 文章标签：驱动开发文件系统

linux 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

由于最近开始学习input子系统杂项设备类总线模型块设备等东西发现它们都跟sys这个目录有关就整理了下这方面的信息求指正哈

讲到sys目录，先讲讲sysfs，sysfs 是 Linux 内核中设计较新的一种虚拟的基于内存的文件系统，（文件系统是什么？好像是对块设备的一种管理机制）。而sys目录就是sysfs文件系统的挂载点。

proc也是对内存信息的映射，如果打开proc文件夹你会看到里面有各进程的进程号，进入 /proc/11 你就会看到里面有该进程的进程号跟内存映射什么的东西。还可以cat /proc/device 看现在到底insmod了多少个设备。总之通过proc 我们就可以看到内存里各个进程的情况，以及知道我们系统内存里的情况。具体的请点击飞机票（/proc 目录详解）

sys把proc里的信息进行归类，并在次基础上引入了类的概念，我们现在的驱动开发都是通过类继承或者总线来开发的，这类开发都会先在驱动里创建一个dev结构体，这样的话就逐渐出现了一个叫设备模型的概念。

sys目录下的子目录，以及这些目录的内容如下：

sys/devices	这是内核对系统中所有设备的分层次表达模型，也是 /sys 文件系统管理设备的最重要的目录结构，下文会对它的内部结构作进一步分析；
/sys/dev	这个目录下维护一个按字符设备和块设备的主次号码(major:minor)链接到真实的设备(/sys/devices下)的符号链接文件，它是在内核 2.6.26 首次引入；
/sys/bus	这是内核设备按总线类型分层放置的目录结构， devices 中的所有设备都是连接于某种总线之下，在这里的每一种具体总线之下可以找到每一个具体设备的符号链接，它也是构成 Linux 统一设备模型的一部分；
/sys/class	这是按照设备功能分类的设备模型，如系统所有输入设备都会出现在 /sys/class/input 之下，而不论它们是以何种总线连接到系统。它也是构成 Linux 统一设备模型的一部分；
/sys/block	这里是系统中当前所有的块设备所在，按照功能来说放置在 /sys/class 之下会更合适，但只是由于历史遗留因素而一直存在于 /sys/block, 但从 2.6.22 开始就已标记为过时，只有在打开了 CONFIG_SYSFS_DEPRECATED 配置下编译才会有这个目录的存在，并且在 2.6.26 内核中已正式移到 /sys/class/block, 旧的接口 /sys/block 为了向后兼容保留存在，但其中的内容已经变为指向它们在 /sys/devices/ 中真实设备的符号链接文件；
/sys/firmware	这里是系统加载固件机制的对用户空间的接口，关于固件有专用于固件加载的一套API，在附录 LDD3 一书中有关于内核支持固件加载机制的更详细的介绍；
/sys/fs	这里按照设计是用于描述系统中所有文件系统，包括文件系统本身和按文件系统分类存放的已挂载点，但目前只有 fuse,gfs2 等少数文件系统支持 sysfs 接口，一些传统的虚拟文件系统(VFS)层次控制参数仍然在 sysctl (/proc/sys/fs) 接口中中；
/sys/kernel	这里是内核所有可调整参数的位置，目前只有 uevent_helper, kexec_loaded, mm, 和新式的 slab 分配器等几项较新的设计在使用它，其它内核可调整参数仍然位于 sysctl (/proc/sys/kernel) 接口中 ;
/sys/module	这里有系统中所有模块的信息，不论这些模块是以内联(inlined)方式编译到内核映像文件(vmlinuz)中还是编译为外部模块(ko文件)，都可能会出现在 `/sys/module` 中：编译为外部模块(ko文件)在加载后会出现对应的 /sys/module/<module_name>/, 并且在这个目录下会出现一些属性文件和属性目录来表示此外部模块的一些信息，如版本号、加载状态、所提供的驱动程序等；编译为内联方式的模块则只在当它有非0属性的模块参数时会出现对应的 /sys/module/<module_name>, 这些模块的可用参数会出现在 `/sys/modules/<modname>/parameters/<param_name>` 中，如 /sys/module/printk/parameters/time 这个可读写参数控制着内联模块 printk 在打印内核消息时是否加上时间前缀；所有内联模块的参数也可以由 "<module_name>.<param_name>=<value>" 的形式写在内核启动参数上，如启动内核时加上参数 "printk.time=1" 与向 "/sys/module/printk/parameters/time" 写入1的效果相同；没有非0属性参数的内联模块不会出现于此。
/sys/power	这里是系统中电源选项，这个目录下有几个属性文件可以用于控制整个机器的电源状态，如可以向其中写入控制命令让机器关机、重启等。
/sys/slab (对应 2.6.23 内核，在 2.6.24 以后移至 /sys/kernel/slab)	从2.6.23 开始可以选择 SLAB 内存分配器的实现，并且新的 SLUB（Unqueued Slab Allocator）被设置为缺省值；如果编译了此选项，在 /sys 下就会出现 /sys/slab ，里面有每一个 kmem_cache 结构体的可调整参数。对应于旧的 SLAB 内存分配器下的 /proc/slabinfo 动态调整接口，新式的 /sys/kernel/slab/<slab_name> 接口中的各项信息和可调整项显得更为清晰。

原来是想整理整理的但是别人写的太好了，也就直接搬过来了

Linux 统一设备模型

在 Linux 2.5 内核的开发过程中，人们设计了一套新的设备模型，目的是为了对计算机上的所有设备进行统一地表示和操作，包括设备本身和设备之间的连接关系。这个模型是在分析了 PCI 和 USB 的总线驱动过程中得到的，这两个总线类型能代表当前系统中的大多数设备类型，它们都有完善的热挺拔机制和电源管理的支持，也都有级连机制的支持，以桥接的 PCI/USB 总线控制器的方式可以支持更多的 PCI/USB 设备。为了给所有设备添加统一的电源管理的支持，而不是让每个设备中去独立实现电源管理的支持，人们考虑的是如何尽可能地重用代码；而且在有层次模型的 PCI/USB 总线中，必须以合理形式展示出这个层次关系，这也是电源管理等所要求的必须有层次结构。

如在一个典型的 PC 系统中，中央处理器(CPU)能直接控制的是 PCI 总线设备，而 USB 总线设备是以一个 PCI 设备(PCI-USB桥)的形式接入在 PCI 总线设备上，外部 USB 设备再接入在 USB 总线设备上；当计算机执行挂起(suspend)操作时， Linux 内核应该以 “外部USB设备->USB总线设备->PCI总线设备” 的顺序通知每一个设备将电源挂起；执行恢复(resume)时则以相反的顺序通知；反之如果不按此顺序则将有设备得不到正确的电源状态变迁的通知，将无法正常工作。

sysfs 是在这个 Linux 统一设备模型的开发过程中的一项副产品(见参考资料中 Greg K. Hartman 写作的 LinuxJournal 文章)。为了将这些有层次结构的设备以用户程序可见的方式表达出来，人们很自然想到了利用文件系统的目录树结构（这是以 UNIX 方式思考问题的基础，一切都是文件！）在这个模型中，有几种基本类型，它们的对应关系见表 2. Linux 统一设备模型的基本结构：

表 2. Linux 统一设备模型的基本结构

类型	所包含的内容	对应内核数据结构	对应/sys项
设备(Devices)	设备是此模型中最基本的类型，以设备本身的连接按层次组织	`struct device`	`/sys/devices///.../`
设备驱动(Device Drivers)	在一个系统中安装多个相同设备，只需要一份驱动程序的支持	`struct device_driver`	`/sys/bus/pci/drivers/*/`
总线类型(Bus Types)	在整个总线级别对此总线上连接的所有设备进行管理	`struct bus_type`	`/sys/bus/*/`
设备类别(Device Classes)	这是按照功能进行分类组织的设备层次树；如 USB 接口和 PS/2 接口的鼠标都是输入设备，都会出现在 /sys/class/input/ 下	`struct class`	`/sys/class/*/`

从内核在实现它们时所使用的数据结构来说， Linux 统一设备模型又是以两种基本数据结构进行树型和链表型结构组织的：

kobject: 在 Linux 设备模型中最基本的对象，它的功能是提供引用计数和维持父子(parent)结构、平级(sibling)目录关系，上面的 device, device_driver 等各对象都是以 kobject 基础功能之上实现的；
```
struct kobject {
        const char              *name;
        struct list_head        entry;
        struct kobject          *parent;
        struct kset             *kset;
        struct kobj_type        *ktype;
        struct sysfs_dirent     *sd;
        struct kref             kref;
        unsigned int state_initialized:1;
	unsigned int state_in_sysfs:1;
        unsigned int state_add_uevent_sent:1;
        unsigned int state_remove_uevent_sent:1;
};
```
其中 struct kref 内含一个 atomic_t 类型用于引用计数， parent 是单个指向父节点的指针， entry 用于父 kset 以链表头结构将 kobject 结构维护成双向链表；内核都是里都是通过链表对设备进行维护的。如果你查阅 struct class || struct device || struct drive_drive || struct bus_type 你会发现里面都有kobject 结构体，说明一点内核会把这些东西串成一个链表来维护。

恩在看了大神的那边文章后我又只能默默的放上一张飞机票啦关于sysfs文件系统跟它是怎么访问linux内核的以及它里面的东西是怎么维护跟构建起来的

都在这张飞机票里 http://www.ibm.com/developerworks/cn/linux/l-cn-sysfs/#icomments