Documentation_driver-model_overview.txt

Chinese translated version of Documentation_driver-model_overview

If you have any comment or update to the content, please contact the
original document maintainer directly.  However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help.  Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.

Chinese maintainer:  <1538850747@qq.com>
---------------------------------------------------------------------
Documentation_driver-model_overview的中文翻译

如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。

中文版维护者： 孙航海  <1538850747@qq.com>
中文版翻译者： 孙航海  <1538850747@qq.com>
中文版校译者： 孙航海  <1538850747@qq.com>

 

 

以下为正文
---------------------------------------------------------------------

 

The Linux Kernel Device Model

Linux内核设备模型

Patrick Mochel <mochel@digitalimplant.org>
Patrick Mochel <mochel@digitalimplant.org>

Drafted 26 August 2002
Updated 31 January 2006

起草于2002年8月26日
于2006年1月31日更新

Overview

概述

~~~~~~~~

The Linux Kernel Driver Model is a unification of all the disparate driver
models that were previously used in the kernel. It is intended to augment the
bus-specific drivers for bridges and devices by consolidating a set of data
and operations into globally accessible data structures.

Linux内核驱动程序模型是对先前在内核中使用的所有不同的驱动程序模型的一个统一。
它的目的是在全局可访问的数据结构中强化统一一组数据和操作从而增强桥接器和设备
的总线特定的驱动程序。

Traditional driver models implemented some sort of tree-like structure
(sometimes just a list) for the devices they control. There wasn't any
uniformity across the different bus types.

传统的驱动程序模型为它们控制的设备使用了某种树状结构（有时只是一个列表）。
不同的总线类型是各不相同的。

The current driver model provides a common, uniform data model for describing
a bus and the devices that can appear under the bus. The unified bus
model includes a set of common attributes which all busses carry, and a set
of common callbacks, such as device discovery during bus probing, bus
shutdown, bus power management, etc.

当前驱动模型提供了一个共有的，统一的数据模型来描述一个总线和会出现在这个总线下
的设备。这种统一的总线模型包括了所有总线携带的一组公共属性和一组公共的回调函数，
例如总线探查,总线关闭,总线电源管理等。

The common device and bridge interface reflects the goals of the modern
computer: namely the ability to do seamless device "plug and play", power
management, and hot plug. In particular, the model dictated by Intel and
Microsoft (namely ACPI) ensures that almost every device on almost any bus
on an x86-compatible system can work within this paradigm.  Of course,
not every bus is able to support all such operations, although most
buses support most of those operations.

普通设备和桥接器接口反映了现代计算机的目标：即有能力实现设备的即插即用,电源
管理,和热插拔功能。特别是由Intel和Microsoft提出的模型（即ACPI）确保了几乎所
有设备能在x86兼容的系统中大多数任意总线这种模式下使用。当然，不是每个总线都
能够支持所有的这些操作，尽管大多数总线支持大部分的这些操作。

Downstream Access

底层访问

~~~~~~~~~~~~~~~~~

Common data fields have been moved out of individual bus layers into a common
data structure. These fields must still be accessed by the bus layers,
and sometimes by the device-specific drivers.

常见的数据字段已经撤离个人总线层到一个共同的数据结构。这些字段必须被总线层，
有时被特定的设备驱动程序访问。

Other bus layers are encouraged to do what has been done for the PCI layer.
struct pci_dev now looks like this:

其他总线层被鼓励去做以前给PCI层做的工作。pci_dev结构如下：

struct pci_dev {
 ...

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

Note first that the struct device dev within the struct pci_dev is
statically allocated. This means only one allocation on device discovery.

首先要注意在结构pci_dev中的struct device dev是静态分配的。这意味着在发现
设备时只有一个分配。

Note also that that struct device dev is not necessarily defined at the
front of the pci_dev structure.  This is to make people think about what
they're doing when switching between the bus driver and the global driver,
and to discourage meaningless and incorrect casts between the two.

还要注意,struct device dev不一定是定义前面的pci_dev结构。这让人们思考在总线
驱动程序与全局驱动程序之间转换时它们做什么，并且去阻止它们之间无意义的和不正
确的转换。

The PCI bus layer freely accesses the fields of struct device. It knows about
the structure of struct pci_dev, and it should know the structure of struct
device. Individual PCI device drivers that have been converted to the current
driver model generally do not and should not touch the fields of struct device,
unless there is a compelling reason to do so.

PCI总线层可以自由访问struct device的字段。它知道struct pci_dev的结构，也应该
知道struct device的结构。单独的PCI设备驱动程序转换到当前驱动程序模型一般不会和
不应接触struct device的字段,除非有令人信服的理由这样做。

The above abstraction prevents unnecessary pain during transitional phases.
If it were not done this way, then when a field was renamed or removed, every
downstream driver would break.  On the other hand, if only the bus layer
(and not the device layer) accesses the struct device, it is only the bus
layer that needs to change.

上述抽象是为了防止在过渡阶段产生的不必要的麻烦.如果它没有这么做，那么当一个字
段的名字变了或是被去除了,那所有底层的驱动将会不可用.另一方面来说,如果只有总线
层(并不是设备层)访问struct device,那就只需修改总线层即可.

User Interface

用户接口

~~~~~~~~~~~~~~

By virtue of having a complete hierarchical view of all the devices in the
system, exporting a complete hierarchical view to userspace becomes relatively
easy. This has been accomplished by implementing a special purpose virtual
file system named sysfs.

由于拥有一个完整的系统中的所有设备的层次结构视图可以相对容易的导出一个完整的分层
视图到用户空间。这是通过实施一个叫sysfs的专用虚拟文件系统完成的。

Almost all mainstream Linux distros mount this filesystem automatically; you
can see some variation of the following in the output of the "mount" command:

几乎所有的主流Linux发行版都会自动安装文件系统；你可以在“mount”命令的输出中看到
一些变化：

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

The auto-mounting of sysfs is typically accomplished by an entry similar to
the following in the /etc/fstab file:

sysfs的自动安装通常是通过一个类似在/etc/fstab条目中的文件完成的：

none      /sys sysfs    defaults    0 0

or something similar in the /lib/init/fstab file on Debian-based systems:

或一些类似在/lib/init/fstab下在多个基于debian系统文件:

none            /sys    sysfs    nodev,noexec,nosuid    0 0

If sysfs is not automatically mounted, you can always do it manually with:

如果sysfs不会自动安装，你可以手动完成：

# mount -t sysfs sysfs /sys

Whenever a device is inserted into the tree, a directory is created for it.
This directory may be populated at each layer of discovery - the global layer,
the bus layer, or the device layer.

无论何时在这个树上插入设备,一个目录都会为它创建.这个目录可能在每个层中出现，
比如全局层,总线层,或设备层.

The global layer currently creates two files - 'name' and 'power'. The
former only reports the name of the device. The latter reports the
current power state of the device. It will also be used to set the current
power state.

在全局层一般创建两个文件-"name"和"power".前者只是列出了设备的名称.后者则
报告设备当前的电源状态.它通常被用来设置当前的电源状态.

The bus layer may also create files for the devices it finds while probing the
bus. For example, the PCI layer currently creates 'irq' and 'resource' files
for each PCI device.

总线层也会为在探测总线时发现的设备创建文件.例如,PCI层一般会为每一个PCI设备创建
'irq'和'resource'文件.

A device-specific driver may also export files in its directory to expose
device-specific data or tunable interfaces.

一个特定设备的驱动程序也可能通过在它的目录下导出文件来公开该设备特定数据或
可调的接口。

More information about the sysfs directory layout can be found in
the other documents in this directory and in the file
Documentation/filesystems/sysfs.txt.

关于sysfs目录布局的更多信息可以查阅当前文件夹中的其它文档和文件
Documentation/filesystems/sysfs.txt.