Linux内核 文档翻译汇总

如果有任何疑问，请联系：[e-mail]内核文档翻译汇总--devicemodel........................................................................................1前言...........................................................................................................................................1Overview...................................................................................................................................2Binding......................................................................................................................................4Bus............................................................................................................................................6Class..........................................................................................................................................9Device.....................................................................................................................................13Devres.....................................................................................................................................17Driver......................................................................................................................................23Interface..................................................................................................................................27Platform...................................................................................................................................30Porting.....................................................................................................................................34前言我们翻译的第一批文档已经翻译出来了，我将这些文档整理到一起，方便大家阅读，下面的工作更加艰巨，就是如何校订我们的文档，保证我们的文档的权威性（准确性）。这不仅需要大家的努力，还需要我们制定良好的校订文档规则。下面是我制定的一些校订规则，如果有什么疑问欢迎各位补充：文档校订规则：0.对进入校订期的文档，请翻译者将文档的最新版本在bbs上发帖公示。在文档的点击率达到100，或者文档翻译完成一周后，翻译者可以准备，申请答辩，答辩必须在群中交流，根据文档的大小确定答辩形式，在一致认为答辩通过后，标记为稳定版本。添加到发行版中。1.答辩规则（一般情况，特殊情况另外说明）--1.答辩者提前一周，在群中发表声明，说明自己的文章需要答辩，并告知负责人[e-mail]。--2.chenyongbiao负责安排答辩时间，并发群邮件通知群成员，在群公告中发表公告。--3.答辩开始，答辩者做简单陈述（所翻译的文章概要）。--4.答辩组成员阅读文章，提出疑问（包括错别字，专用名词等）。--5.答辩完成，答辩者综合考虑答辩组成员的意见，整理文档。将答辩完的文章公示，并注明已通过答辩，这阶段主要是让大家找文章中的错别字等。--7.公示一周后，文章正式添加进发行版。2.文档提交。如果有任何疑问，请快联系我：[e-mail],下一步我们将执行校订方案。Overview翻译者：宙翰[e-mail]内核设备模型[e-mail]起草于2002年8月26日于2006年1月31日更新概述~~~~~~~~Linux内核设备模型是对所有以前在内核中以前使用过的不同驱动模型的一种统一.它设是通过把一组数据和操作统一到全局可访问的数据结构中来为桥接器和设备增加总线专有驱动.传统的驱动模型给它所控制的设备实现了一系列的树形结构(有些仅仅是一个链表).他们在不同类型的总线设备上区别很大.现在的驱动模型给描述一种总线和会出现在这个总线下的设备提供了一种公共的,统一的数据模型.这种统一的总线模型包括了一组所有总线都有的公共属性和一组公共的回掉函数,例如能在总线枚举,总线关闭和总线电源管理.通用设备和桥接器接口也体现了现代计算机的目标:也就是实现设备的即插即用,电源管理和热插拔功能.特别是由Intel和Microsoft提出的的模型(即ACPI),它确保了几乎所有的设备能在和X86兼容的系统中大多数任意总线上使用.当然并不是每一个总线都能够支持所有这些操作,但几乎所有的总线支持大多数这样的操作.底层访问~~~~~~~~公共的数据项已经从单个总线中移到了公用数据结构中.当然总线层仍然可以访问这些域,有时也要可被设备专有驱动所访问.结构如下:复制内容到剪贴板代码:structpci_dev{...structdevicedev;};首先要注意的是这个结构是静态分配的.也就是说在发现设备时只会分配一个.另外要注意的是pci_dev结构末尾的device结构。这是用来防止编程者混淆device和pci_dev。PCI总线层可以自如的访问结构structdevice中的各成员.要了解pci_dev这个数据结构,也应该知道devibe这个数据结构.已经被转换成当前驱动模型的单独的PCI设备驱动不要也不应该去动device结构中的成员,除非有强烈的令人信服的理由才去这么做.这种抽象是为了防止在过渡期间产生的不必要的麻烦.如果一个成员的名字变了或是被去除了,那所有底层的驱动将会不可用.另一方面来说,如果只有总线层(并不是设备层)访问device结构,那就只需修改需要修改的那一层即可.用户接口~~~~~~~这种对系统中所有设备进行一种完全分层的组织的好处是可以相对容易的给用户空间提供一种完全分层次的设备关系图.通过实现一种称之谓sysfs的特殊的虚拟文件系统内核已经实现了这样的组织视图.因此用户就可以在用户空间的任意点挂载这个完整的sysfs文件系统.也可以把下面的语句添加到/etc/fstab中来实现挂载:复制内容到剪贴板代码:sysfs/syssysfsdefaults00Orbyhandonthecommandline:或者在命令行下敲如下的命令进行挂载:复制内容到剪贴板代码:#mount-tsysfssysfs/sys无论何时在这个树上插入设备,内核都会为它创建一个目录.这个目录可能在每个层中出现比如全局层,总线层,或设备层.在全局层一般创建两个文件-name和power.只是列出了设备的名称.后一个是描述设备当前的电源状态.它通常被用来设置当前的电源状态.总线层也会为在探测时发现的设备创建文件.例如,PCI层一般会为每一个PCI设备创建'irq'和'resource'文件.特定设备的驱动程序也可能会在它的目录下通过创建文件来导出该设备的数据或提供调整的接口？更多关于sysfs目录布局的信息可以查阅当前文件夹中的其它文档和文件Documentation/filesystems/sysfs.txt.Binding原文作者：翻译者：[e-mail]校订者：版本状态：还未完成======================================驱动程序绑定~~~~~~~~~~~~~~~~~~~~~~~~~~~驱动程序绑定是把设备与能够控制该设备的驱动程序关联的过程。典型的情况下，由总线驱动程序来处理绑定，因为每一种总线都有自己特定的结构体来表示设备和设备驱动。有了表示设备和设备驱动程序的通用结构体，大部分的绑定工作使用同样的代码就可以完成。总线~~~表示总线类型的结构体包含了系统里面连接在这种总线上的所有设备的列表。为某个设备调用device_register的时候，该设备就被插到列表的末端。这个结构体里面也包含了总线上所有驱动程序的的列表。当为某个驱动程序调用dirver_register的时候，该驱动程序就被插到列表的末端。这两个事件触发了驱动程序绑定。device_register~~~~~~~~~~~~~~~添加新设备的时候，系统扫描总线的驱动程序列表，试图找到支持该设备的驱动程序。如何确定驱动程序支不支持该设备呢？就看设备标识符(deviceID)是不是与驱动程序支持的所有设备标识符的其中一个相匹配。设备标识符的格式和语义因总线而异。与其推导一个复杂的状态自动机和匹配算法，通常是交由总线驱动程序提供一个匹配设备和驱动程序的回调函数。如果匹配成功，回调函数返回1；否则返回0.intmatch(structdevice*dev,structdevice_driver*drv);如果匹配成功，系统将设备的driver域置为该驱动程序，并调用驱动程序的probe回调函数，以检测驱动程序是否确实支持这个硬件，同时确定设备是否处于工作状态。设备类型~~~~~~~~~~~~probe成功完成调用后，设备被注册到它所属的设备类型中。设备驱动程序属于唯一一个类型，记录在设备结构体的devclass域中。在设备类型的register_dev回调函数中，会调用devclass_add_device遍历该类型下的所有设备并注册该设备。注意：设备类型结构体以及操作它们的系统调用并不包含在主流的内核中，所以我们这里的讨论多少有点推测的味道。驱动程序~~~~~~当驱动程序关联到设备上时，该设备被插到驱动程