网站大量收购闲置独家精品文档,联系QQ:2885784924

Linux内核文档翻译汇总.doc

  1. 1、本文档共42页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
Linux内核文档翻译汇总.doc

Linux内核文档翻译汇总--device model 如果有任何疑问,请联系:xuluping87@ Linux内核文档翻译汇总--device model 1 前言 1 Overview 2 Binding 4 Bus 6 Class 9 Device 13 Devres 17 Driver 23 Interface 27 Platform 30 Porting 34 前言 我们翻译的第一批文档已经翻译出来了,我将这些文档整理到一起,方便大家阅读,下面的工作更加艰巨,就是如何校订我们的文档,保证我们的文档的权威性(准确性)。这不仅需要大家的努力,还需要我们制定良好的校订文档规则。 下面是我制定的一些校订规则,如果有什么疑问欢迎各位补充: 文档校订规则: 0. 对进入校订期的文档,请翻译者将文档的最新版本在bbs上发帖公示。 在文档的点击率达到100,或者文档翻译完成一周后,翻译者可以准备,申请答辩,答辩必须在群中交流,根据 文档的大小确定答辩形式,在一致认为答辩通过后,标记为稳定版本。添加到发行版中。 1. 答辩规则(一般情况,特殊情况另外说明) --1. 答辩者提前一周,在群中发表声明,说明自己的文章需要答辩,并告知负责人chenyongbiao87@。 --2. chenyongbiao负责安排答辩时间,并发群邮件通知群成员,在群公告中发表公告。 --3. 答辩开始,答辩者做简单陈述(所翻译的文章概要)。 --4. 答辩组成员阅读文章,提出疑问(包括错别字,专用名词等)。 --5. 答辩完成,答辩者综合考虑答辩组成员的意见,整理文档。 --6. 将答辩完的文章公示,并注明已通过答辩,这阶段主要是让大家找文章中的错别字等。 --7. 公示一周后,文章正式添加进发行版。 文档提交。 如果有任何疑问,请快联系我:xuluping87@,下一步我们将执行校订方案。 Overview 翻 译者:宙翰 ourkernel@ Linux内核设备模型 Patrick Mochel mochel@ 起草于 2002年 8月26日 于2006年1月31日更新 概述 ~~~~~~~~ Linux内核设备模型是对所有以前在内核中以前使用过的不同驱动模型的一种统一.它设是通过把一组数据和操作统一到全局可访问的数据结构中来为桥接器和设备增加总线专有驱动. 传统的驱动模型给它所控制的设备实现了一系列的树形结构(有些仅仅是一个链表).他们在不同类型的总线设备上区别很大. 现在的驱动模型给描述一种总线和会出现在这个总线下的设备提供了一种公共的,统一的数据模型.这种统一的总线模型包括了一组所有总线都有的公共属性和一组公共的回掉函数,例如能在总线枚举,总线关闭和总线电源管理. 通用设备和桥接器接口也体现了现代计算机的目标:也就是实现设备的即插即用,电源管理和热插拔功能.特别是由Intel和Microsoft提出的的模型(即ACPI),它确保了几乎所有 的设备能在和X86兼容的系统中大多数任意总线上使用.当然并不是每一个总线都能够支持 所有这些操作,但几乎所有的总线支持大多数这样的操作. 底层访问 ~~~~~~~~ 公共的数据项已经从单个总线中移到了公用数据结构中.当然总线层仍然可以访问这些域,有时也要可被设备专有驱动所访问. 其它的总线层被用来做以前给PCI层所做的那些工作.pci_dev结构如下: 复制内容到剪贴板 代码: struct pci_dev { ... struct device dev; }; 首先要注意的是这个结构是静态分配的.也就是说在发现设备时只会分配一个.另外要注意 的是pci_dev结构末尾的device结构。这是用来防止编程者混淆device和pci_dev。 PCI总线层可以自如的访问结构struct device中的各成员.要了解pci_dev这个数据结构, 也应该知道devibe这个数据结构.已经被转换成当前驱动模型的单独的PCI设备驱动不要也 不应该去动device结构中的成员,除非有强烈的令人信服的理由才去这么做. 这种抽象是为了防止在过渡期间产生的不必要的麻烦.如果一个成员的名字变了或是被去 除了,那所有底层的驱动将会不可用.另一方面来说,如果只有总线层(并不是设备层)访问 device结构,那就只需修改需要修改的那一层即可. 用户接口 ~~~~~~~ 这种对系统中所有设备进行一种完全分层的组织的好处是可以相对容易的给用户空间提供 一种完全分层次的设备关系图.通过实现一种称之谓sysfs的特殊的虚拟文件系统内核已经 实现了这样的组织视图.因此用户就可以在用户空间的任意点挂载这个完整的sysfs文件系统. 也可以把下

文档评论(0)

dmz158 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档