|
|
EDA365欢迎您登录！
您需要 登录 才可以下载或查看，没有帐号？注册
x
0 \5 ?! T# S$ q0 O& P3 a随着计算机的周边外设越来越丰富，设备管理已经成为现代操作系统的一项重要任务，这对于Linux来说也是同样的情况。每次Linux内核新版本的发布，都会伴随着一批设备驱动进入内核。在Linux内核里，驱动程序的代码量占有了相当大的比重。下图是我在网络上搜索到的一幅Linux内核代码量的统计图，对应的内核版本是2.6.29。
, W2 D& p1 K/ F) U/ _1 y+ h0 l, ?" C: @1 W( j1 u6 b
1 v# p6 a+ U) w: I, E$ X3 v* G5 F# i4 J! X1 g
我们可以很明显的看到，在Linux内核中驱动程序的比例已经非常高了。
/ W: \" d$ ?, t+ }7 n
0 i2 X4 }' x D' a Y0 \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设备模型的目的。
1 G6 g, v5 N* M- M) `+ S4 I
1 f2 o* b6 j I+ `当然，Linux设备模型给我们带来的便利远不止如此。既然已经建立了一个组织所有设备和驱动的树状结构，用户就可以通过这棵树去遍历所有的设备，建立设备和驱动程序之间的联系，根据类型不同也可以对设备进行归类，这样就可以更清晰的去“看”这颗枝繁叶茂的大树。另外，Linux驱动模型把很多设备共有的一些操作抽象出来，大大减少了重复造轮子的可能。同时Linux设备模型提供了一些辅助的机制，比如引用计数，让开发者可以安全高效的开发驱动程序。达成了以上这些好处之后，我们还得到了一个非常方便的副产品，这就是sysfs----一个虚拟的文件系统。sysfs给用户提供了一个从用户空间去访问内核设备的方法，它在Linux里的路径是/sys。这个目录并不是存储在硬盘上的真实的文件系统，只有在系统启动之后才会建起来。/ B' M x7 B q/ U- A
$ j. W- r% L2 s( u' _+ E! ?
下面这个命令可以用来显示sysfs的大致结构：
* ?/ d4 ~& D2 A5 T; v2 F8 q4 w- D- [$ W" K- y
tree /sys% m a3 H* U: z) M: _* W
0 V: a& j) g% d+ z) d9 g这个命令的信息量非常大，我就不贴出来了，如果有兴趣的话可以看看这里，或者自己动手实验一下。8 h3 [: z- M+ h1 X% J% M
& a! |# Q. F5 p" [我们来看看第一层目录结构：
3 \5 g2 e7 N# T; a* f8 i! R, {
" P& k) O" y+ k/ F/sys
0 B# k; l( g0 [, b6 [9 A3 n7 S|-- block
+ X) j) H3 j7 Y& ]7 q|-- bus& i' i0 F( [! Z
|-- class1 ]& {4 j& o) I9 I4 u
|-- dev
+ e7 Y1 w. [0 u* w$ ^! y) t M|-- devices
; _8 |2 t0 S- [- W! \( O: w0 {|-- firmware
! ?6 V2 x: a& ?. o/ U$ C9 b|-- fs# a7 g$ n7 ~4 w4 Q2 r
|-- kernel3 k7 B4 h& J# C1 a4 P6 d
|-- module
6 K, H+ _8 T( A/ w) a$ }`-- power& g/ g( M: V8 W9 H9 V) O
# q' m3 `0 {, p, p5 h* d5 d
这里有10个子目录，但并不是说这10个目录代表了10种完全不同的设备类型，实际上这些目录只是给我们提供了如何去看整个设备模型的不同的视角。其实从不同的目录出发都有可能找到同一个设备的。那真正的设备信息到底放在哪里呢？看看目录的名称就应该能猜到，对，就是devices子目录，Linux的所有设备都可以在这个目录里找到。这里是一个大杂烩，虽然五脏俱全但我们却无从下手。这里还是以U盘为例，插上U盘之后，在devices目录里如何找到这支U盘呢？真得很难办到。但是如果知道这个U盘在系统里的设备文件名（暂且假设为sdb），那就可以从block目录着手。9 X1 p. l. P! @! c- y3 u0 ^% z; f/ J) K
& e2 O1 [ ?0 F ~( Z( u) @
/ S }2 y6 W! S
$ C7 Q" ?1 Q' q3 w% r
透过block目录，我们很容易就可以找到这个U盘设备，符号链接device正是指向devices目录下的位置。5 @6 h# G! _8 M. Y' T# @; {* V0 _
% f- |' i i1 @5 {5 P/ X. B4 ~) ^到这里，我们总结一下/sys目录下各个子目录的作用。block目录是从块设备的角度来组织设备；bus目录是从系统总线这个角度来组织设备，比如PCI总线或者USB总线；class目录把看问题的视角提高到了类别的高度，比如PCI设备或者USB设备等；dev目录的视角是设备节点；devices目录在前面提到了，这里是所有设备的大本营；firmware目录包含了一些比较低阶的子系统，比如ACPI、EFI等；fs目录里看到的是系统支持的所有文件系统；kernel目录下包含的是一些内核的配置选项；modules目录下包含的是所有内核模块的信息，内核模块实际上和设备之间是有对应关系的，通过这个目录顺藤摸瓜找到devices或者反过来都是可以做到的；power目录存放的是系统电源管理的数据，用户可以通过它来查询目前的电源状态，甚至可以直接“命令”系统进入休眠等省电模式。4 i# X( o% f1 z$ w% \5 Q5 ]
l8 D3 I1 t) G6 ?
sysfs正是用户和内核设备模型之间的一座桥梁，通过这个桥梁我们可以从内核中读取信息，也可以向内核里写入信息。% ?; \$ M8 H1 c
1 t- z8 @8 f1 H b9 \: ^/ E, X
在Linux里也可以找到一些图形化的工具来查询设备信息。比如GNOME下基于HAL的Device Manager：
6 A6 i& J" l# x; \, R, _
% `3 X% K& t: Z# b, ]) ~+ a8 x
; n& _% y0 `3 r3 F
7 p- W# H6 X/ x5 N8 ^+ G' s或者KDE下基于Solid的KInfoCenter：6 @4 K: a, U& t
8 t. m" J2 h) \; U
! @4 ]% G& b3 ~& E8 B6 k
! M; b9 L" h1 n2 X这些图形化的工具提供了更加直观的方式来访问设备，但是它们的提供的信息还不够全面，而且没有向内核设备写数据的功能。' h& a6 A1 [( a& D/ J6 { d+ ~9 n- y
1 j: C* D2 O" g& _" D如果具体到某一类型的设备，Linux下还有一些专用的工具可以使用。比如面向PCI设备的pciutils，面向USB设备的usbutils，以及面向SCSI设备的lsscsi等。对于Linux开发者来说，有时使用这些专用的工具更加方便。7 q; x+ E( K; ~6 O0 h4 u, y
& L" x$ X( ]! ?- S3 v# M我们如果要写程序来访问sysfs，可以像读写普通文件一样来操作/sys目录下的文件，或者，也可以使用libsysfs。不过需要注意的是，Linux内核社区并不推荐用libsysfs，因为这个API的更新不够快，赶不上内核的变化。libsysfs已经逐渐背离最初创建它的目标，这个lib带来的问题似乎比它解决的还要多。当然，如果只是要访问设备，一般很少会直接操作sysfs，它太细节太底层了，大部分情况下可以使用更加方便的DeviceKit或者libudev。3 p* b6 {# x P- \4 H* ]- C+ [
# t7 m8 c3 g5 F9 P
$ q' z9 K% m; ^6 m3 F8 E
总结一下，本文主要简单介绍了Linux设备模型的基本概念和虚拟文件系统sysfs。接下来的篇章里将和大家继续探讨设备模型在内核空间的一些细节。7 C: {+ i9 O1 ~; o! t
7 f7 A( U* v% {. e8 W; u; j# e
|
|
/1 
发表于 2021-6-7 10:37
收藏
淘帖
支持！
反对！