Documentation / zh_CN / HOWTO

Based on kernel version 2.6.26. Page generated on 2008-07-16 21:13 EST.

	Chinese translated version of Documentation/HOWTO
	
	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.
	
	Maintainer: Greg Kroah-Hartman <greg[AT]kroah[DOT]com>
	Chinese maintainer: Li Yang <leoli[AT]freescale[DOT]com>
	---------------------------------------------------------------------
	Documentation/HOWTO 的中文翻译
	
	如果想评论或更新本文的内容，请直接�系原文档的维护者。如果你使用英文
	交�有困难的�，也�以�中文版维护者求助。如果本翻译更新��时或者翻
	译存在问题，请�系中文版维护者。
	
	英文版维护者： Greg Kroah-Hartman <greg[AT]kroah[DOT]com>
	中文版维护者： �阳  Li Yang <leoli[AT]freescale[DOT]com>
	中文版翻译者： �阳  Li Yang <leoli[AT]freescale[DOT]com>
	中文版校译者： 钟宇  TripleX Chung <xxx.phy[AT]gmail[DOT]com>
	               陈�  Maggie Chen <chenqi[AT]beyondsoft[DOT]com>
	               王�  Wang Cong <xiyou.wangcong[AT]gmail[DOT]com>
	
	以下为正文
	---------------------------------------------------------------------
	
	如何�与Linux内核开�
	---------------------
	
	这是一篇将如何�与Linux内核开�的相关问题一网打尽的终�秘笈。它将指导你
	�为一�Linux内核开�者，并且学会如何�Linux内核开�社区�作。它尽�能�
	包括任何关于内核编程的技术细节，但会给你指引一�获得这些知识的正确途径。
	
	如果这篇文章中的任何内容��适用，请给文末列出的文件维护者��补�。
	
	
	入门
	----
	
	你想了解如何�为一�Linux内核开�者？或者����你“给这个设备写个Linux
	驱动程��？这篇文章的目的就是教会你达�这些目标的全部诀�，它将�述你需
	��过的�程以�给出如何�内核社区�作的一些�示。它还将试图解释内核社区
	为何这样�作。
	
	Linux内核大部分是由C语言写�的，一些体系结构相关的代�用到了汇编语言。�
	�与内核开�，你必须精通C语言。除�你想为�个架构开�底层代�，�则你并
	�需�了解（任何体系结构的）汇编语言。下�列举的书�虽然�能替代扎实的C
	语言教育和多年的开��验，但如果需�的�，�为�考还是�错的：
	 - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
	   《C程�设计语言（第2版·新版）》（��文 �志 译）[机械工业出版社]
	 - "Practical C Programming" by Steve Oualline [O'Reilly]
	   《实用C语言编程（第三版）》（郭大海 译）[中国电力出版社]
	 - "C:  A Reference Manual" by Harbison and Steele [Prentice Hall]
	   《C语言�考手册（原书第5版）》（邱仲潘 等译）[机械工业出版社]
	
	Linux内核使用GNU C和GNU工具链开�。虽然它�循ISO C89标准，但也用到了一些
	标准中没有定义的扩展。内核是自给自足的C环境，��赖于标准C库的支�，所以
	并�支�C标准中的部分定义。比如long long类型的大数除法和浮点�算就��许
	使用。有时候确实很难弄清楚内核对工具链的�求和它所使用的扩展，�幸的是目
	�还没有明确的�考资料�以解释它们。请查阅gcc信�页（使用“info gcc�命令
	显示）获得一些这方�信�。
	
	请记�你是在学习怎么和已�存在的开�社区打交�。它由一群形形色色的人组�，
	他们对代��风格和过程有�很高的标准。这些标准是在长期实践中总结出�的，
	适应于地�上分散的大型开�团队。它们已�被很好得整��档，建议你在开�
	之�尽�能多的学习这些标准，而��期望别人�适应你或者你公�的行为方�。
	
	
	法律问题
	--------
	
	Linux内核�代�都是在GPL（通用公共许��）的�护下�布的。�了解这�许�
	的细节请查看�代�主目录下的COPYING文件。如果你对它还有更深入问题请�系
	律师，而��在Linux内核邮件组上�问。因为邮件组里的人并�是律师，��期
	望他们的�有法律效力。
	
	对于GPL的常�问题和解答，请访问以下链接：
		http://www.gnu.org/licenses/gpl-faq.html
	
	
	文档
	----
	
	Linux内核代�中包�有大�的文档。这些文档对于学习如何与内核社区互动有�
	��估�的价值。当一个新的功能被加入内核，最好把解释如何使用这个功能的文
	档也放进内核。当内核的改动导致��用户空间的接��生�化时，最好将相关信
	�或手册页(manpages)的补��到mtk.manpages[AT]gmail[DOT]com，以�手册页(manpages)
	的维护者解释这些�化。
	
	以下是内核代�中需�阅读的文档：
	  README
	    文件简�介�了Linux内核的背景，并且�述了如何�置和编译内核。内核的
	    新用户应该从这里开始。
	
	  Documentation/Changes
	    文件给出了用�编译和使用内核所需�的最�软件包列表。
	
	  Documentation/CodingStyle
	    �述Linux内核的代�风格和�由。所有新代�需��守这篇文档中定义的规
	    范。大多数维护者�会接收符�规定的补�，很多人也�会帮忙检查符�风格
	    的代�。
	
	  Documentation/SubmittingPatches
	  Documentation/SubmittingDrivers
	    这两份文档明确�述如何创建和��补�，其中包括（但�仅�于)：
	       - 邮件内容
	       - 邮件格�
	       - 选择收件人
	    �守这些规定并�能���交�功（因为所有补�需�通过严格的内容和风格
	    审查），但是忽视他们几乎就�味�失败。
	
	    其他关于如何正确地生�补�的优秀文档包括：
	    "The Perfect Patch"
	        http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
	    "Linux kernel patch submission format"
	        http://linux.yyz.us/patch-format.html
	
	  Documentation/stable_api_nonsense.txt
	    论�内核为什么特��包括稳定的内核内部API，也就是说�包括�这样的特
	    性：
	       - �系统中间层（为了兼容性？）
	       - 在���作系统间易于移�的驱动程�
	       - �缓（甚至阻止）内核代�的快速�化
	    这篇文档对于�解Linux的开�哲学至关��。对于将开�平�从其他�作系
	    统转移到Linux的人�说也很��。
	
	  Documentation/SecurityBugs
	    如果你认为自己�现了Linux内核的安全性问题，请根�这篇文档中的步骤�
	    �醒其他内核开�者并帮助解决这个问题。
	
	  Documentation/ManagementStyle
	    �述内核维护者的工作方法�其共有特点。这对于刚刚接触内核开�（或者对
	    它感到好奇）的人�说很��，因为它解释了很多对于内核维护者独特行为的
	    普�误解与迷惑。
	
	  Documentation/stable_kernel_rules.txt
	    解释了稳定版内核�布的规则，以�如何将改动放入这些版本的步骤。
	
	  Documentation/kernel-docs.txt
	    有助于内核开�的外部文档列表。如果你在内核自带的文档中没有找到你想找
	    的内容，�以查看这些文档。
	
	  Documentation/applying-patches.txt
	    关于补�是什么以�如何将它打在��内核开�分支上的好介�
	
	内核还拥有大�从代�自动生�的文档。它包�内核内部API的全�介�以�如何
	妥善处�加�的规则。生�的文档会放在 Documentation/DocBook/目录下。在内
	核��的主目录中使用以下��命令将会分别生�PDF�Postscript�HTML和手册
	页等��格�的文档：
	    make pdfdocs
	    make psdocs
	    make htmldocs
	    make mandocs
	
	
	如何�为内核开�者
	------------------
	如果你对Linux内核开�一无所知，你应该访问“Linux内核新手�计划：
		http://kernelnewbies.org
	它拥有一个�以问��最基本的内核开�问题的邮件列表（在�问之�一定�记得
	查找已往的邮件，确认是�有人已�回答过相�的问题）。它还拥有一个�以获得
	实时�馈的IRC�天频�，以�大�对于学习Linux内核开�相当有帮助的文档。
	
	网站简�介�了�代�组织结构��系统划分以�目�正在进行的项目（包括内核
	中的和�独维护的）。它还�供了一些基本的帮助信�，比如如何编译内核和打补
	�。
	
	如果你想加入内核开�社区并�助完�一些任务，�找�到从哪里开始，�以访问
	“Linux内核房管员�计划：
		http://janitor.kernelnewbies.org/
	这是�佳的起点。它�供一个相对简�的任务列表，列出内核代�中需�被�新
	整�或者改正的地方。通过和负责这个计划的开�者们一�工作，你会学到将补�
	集�进内核的基本原�。如果还没有决定下一步��什么的�，你还�能会得到方
	�性的指点。
	
	如果你已�有一些现�的代�想�放到内核中，但是需�一些帮助�使它们拥有正
	确的格�。请访问“内核导师�计划。这个计划就是用�帮助你完�这个目标的。它
	是一个邮件列表，地�如下：
		http://selenic.com/mailman/listinfo/kernel-mentors
	
	在真正动手修改内核代�之�，�解�修改的代�如何�作是必需的。�达到这个
	目的，没什么办法比直接读代�更有效了（大多数花招都会有相应的注释），而且
	一些特制的工具还�以�供帮助。例如，“Linux代�交�引用�项目就是一个值得
	特别推�的帮助工具，它将�代�显示在有编目和索引的网页上。其中一个更新�
	时的内核��库，�以通过以下地�访问：
		http://sosdg.org/~coywolf/lxr/
	
	
	开��程
	--------
	
	目�Linux内核开��程包括几个“主内核分支�和很多�系统相关的内核分支。这
	些分支包括：
	  - 2.6.x主内核��树
	  - 2.6.x.y -stable内核��树
	  - 2.6.x -git内核补�集
	  - 2.6.x -mm内核补�集
	  - �系统相关的内核��树和补�集
	
	
	2.6.x内核主��树
	-----------------
	2.6.x内核是由Linus Torvalds（Linux的创造者）亲自维护的。你�以在
	kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开��循以下步
	骤：
	  - �当一个新版本的内核被�布，为期两周的集�窗�将被打开。在这段时间里
	    维护者�以�Linus�交大段的修改，通常这些修改已�被放到-mm内核中几个
	    星期了。�交大�修改的首选方�是使用git工具（内核的代�版本管�工具
	    ，更多的信��以在http://git.or.cz/获�），�过使用普通补�也是�以
	    的。
	  - 两个星期以�-rc1版本内核�布。之��有�包��能影�整个内核稳定性的
	    新功能的补���能被接�。请注�一个全新的驱动程�（或者文件系统）有
	    �能在-rc1�被接�是因为这样的修改完全独立，�会影�其他的代�，所以
	    没有造�内核退步的风险。在-rc1以�也�以用git�Linus�交补�，�过所
	    有的补�需��时被��到相应的公众邮件列表以�询��。
	  - 当Linus认为当�的git��树已�达到一个���全的状�足以�布供人测试
	    时，一个新的-rc版本就会被�布。计划是�周都�布新的-rc版本。
	  - 这个过程一直�续下去直到内核被认为达到足够稳定的状�，�续时间大概是
	    6个星期。
	  - 以下地�跟踪了在�个-rc�布中�现的退步列表：
	    http://kernelnewbies.org/known_regressions
	
	关于内核�布，值得一�的是Andrew Morton在linux-kernel邮件列表中如是说：
		“没有人知�新内核何时会被�布，因为�布是根�已知bug的情况�决定
		的，而�是根�一个事先制定好的时间表。�
	
	
	2.6.x.y -stable（稳定版）内核��树
	-----------------------------------
	由4个数字组�的内核版本�说明此内核是-stable版本。它们包�基于2.6.x版本
	内核的相对较�且至关��的修补，这些修补针对安全性问题或者严�的内核退步。
	
	这�版本的内核适用于那些期望获得最新的稳定版内核并且�想�与测试开�版或
	者实验版的用户。
	
	如果没有2.6.x.y版本内核存在，那么最新的2.6.x版本内核就相当于是当�的稳定
	版内核。
	
	2.6.x.y版本由“稳定版��组（邮件地�<stable[AT]kernel[DOT]org>）维护，一般隔周�
	布新版本。
	
	内核��中的Documentation/stable_kernel_rules.txt文件具体�述了�被稳定
	版内核接�的修改类型以��布的�程。
	
	
	2.6.x -git补�集
	----------------
	Linus的内核��树的�日快照，这个��树是由git工具管�的（由此得�）。这
	些补�通常�天更新以�映Linus的��树的最新状�。它们比-rc版本的内核��
	树更具试验性质，因为这个补�集是全自动生�的，没有任何人�确认其是�真正
	�全。
	
	
	2.6.x -mm补�集
	---------------
	这是由Andrew Morton维护的试验性内核补�集。Andrew将所有�系统的内核��
	和补�拼凑到一起，并且加入了大�从linux-kernel邮件列表中采集的补�。这个
	��树是新功能和补�的试炼场。当补�在-mm补�集里�明了其价值以�Andrew
	或者相应�系统的维护者会将补��给Linus以便集�进主内核��树。
	
	在将所有新补��给Linus以集�到主内核��树之�，我们�常鼓励先把这些补
	�放在-mm版内核��树中进行测试。
	
	这些内核版本�适�在需�稳定�行的系统上�行，因为�行它们比�行任何其他
	内核分支都更具有风险。
	
	如果你想为内核开�进程�供帮助，请�试并使用这些内核版本，并在
	linux-kernel邮件列表中�供�馈，告诉大家你�到了问题还是一切正常。
	
	通常-mm版补�集�光包括这些�外的试验性补�，还包括�布时-git版主��树
	中的改动。
	
	-mm版内核没有固定的�布周期，但是通常在�两个-rc版内核�布之间都会有若干
	个-mm版内核�布（一般是1至3个）。
	
	
	�系统相关内核��树和补�集
	----------------------------
	相当一部分内核�系统开�者会公开他们自己的开���树，以便其他人能了解内
	核的��领域正在�生的事情。如上所述，这些��树会被集�到-mm版本内核中。
	
	下�是目��用的一些内核��树的列表：
	  通过git管�的��树：
	    - Kbuild开���树， Sam Ravnborg <sam[AT]ravnborg[DOT]org>
		git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
	
	    - ACPI开���树, Len Brown <len.brown[AT]intel[DOT]com>
		git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
	
	    - �设备开���树, Jens Axboe <axboe[AT]suse[DOT]de>
		git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
	
	    - DRM开���树, Dave Airlie <airlied[AT]linux[DOT]ie>
		git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
	
	    - ia64开���树, Tony Luck <tony.luck[AT]intel[DOT]com>
		git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
	
	    - ieee1394开���树, Jody McIntyre <scjody[AT]modernduck[DOT]com>
		git.kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git
	
	    - infiniband开���树, Roland Dreier <rolandd[AT]cisco[DOT]com>
		git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
	
	    - libata开���树, Jeff Garzik <jgarzik[AT]pobox[DOT]com>
		git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
	
	    - 网络驱动程�开���树, Jeff Garzik <jgarzik[AT]pobox[DOT]com>
		git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
	
	    - pcmcia开���树, Dominik Brodowski <linux[AT]dominikbrodowski[DOT]net>
		git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
	
	    - SCSI开���树, James Bottomley <James.Bottomley[AT]SteelEye[DOT]com>
		git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
	
	  使用quilt管�的补�集：
	    - USB, PCI, 驱动程�核心和I2C, Greg Kroah-Hartman <gregkh[AT]suse[DOT]de>
		kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
	    - x86-64, 部分i386, Andi Kleen <ak[AT]suse[DOT]de>
		ftp.firstfloor.org:/pub/ak/x86_64/quilt/
	
	  其他内核��树�以在http://git.kernel.org的列表中和MAINTAINERS文件里
	  找到。
	
	报告bug
	-------
	
	bugzilla.kernel.org是Linux内核开�者们用�跟踪内核Bug的网站。我们鼓励用
	户在这个工具中报告找到的所有bug。如何使用内核bugzilla的细节请访问：
		http://test.kernel.org/bugzilla/faq.html
	
	内核��主目录中的REPORTING-BUGS文件里有一个很好的模�。它指导用户如何报
	告�能的内核bug以�需��供哪些信��帮助内核开�者们找到问题的根�。
	
	
	利用bug报告
	-----------
	
	练习内核开�技能的最好办法就是修改其他人报告的bug。你�光�以帮助内核�
	得更加稳定，还�以学会如何解决实际问题从而�高自己的技能，并且让其他开�
	者感�到你的存在。修改bug是赢得其他开�者赞誉的最好办法，因为并�是很多
	人都喜欢浪费时间去修改别人报告的bug。
	
	��试修改已知的bug，请访问http://bugzilla.kernel.org网�。如果你想获得
	最新bug的通知，�以订阅bugme-new邮件列表（�有新的bug报告会被寄到这里）
	或者订阅bugme-janitor邮件列表（所有bugzilla的�动都会被寄到这里）。
	
		http://lists.osdl.org/mailman/listinfo/bugme-new
		http://lists.osdl.org/mailman/listinfo/bugme-janitors
	
	
	邮件列表
	--------
	
	正如上�的文档所�述，大多数的骨干内核开�者都加入了Linux Kernel邮件列
	表。如何订阅和退订列表的细节�以在这里找到：
		http://vger.kernel.org/vger-lists.html#linux-kernel
	网上很多地方都有这个邮件列表的存档(archive)。�以使用�索引擎�找到这些
	存档。比如：
		http://dir.gmane.org/gmane.linux.kernel
	在�信之�，我们强烈建议你先在存档中�索你想�讨论的问题。很多已�被详细
	讨论过的问题�在邮件列表的存档中�以找到。
	
	大多数内核�系统也有自己独立的邮件列表��调�自的开�工作。从
	MAINTAINERS文件中�以找到���题对应的邮件列表。
	
	很多邮件列表架设在kernel.org�务器上。这些列表的信��以在这里找到：
		http://vger.kernel.org/vger-lists.html
	
	在使用这些邮件列表时，请记���良好的行为习惯。下�的链接�供了与这些列
	表（或任何其它邮件列表）交�的一些简�规则，虽然内容有点滥竽充数。
		http://www.albion.com/netiquette/
	
	当有很多人回�你的邮件时，邮件的抄�列表会�得很长。请��将任何人从抄�
	列表中删除，除�你有足够的�由这么�。也���回�到邮件列表。请习惯于�
	一�邮件接收两次（一��自��者一��自邮件列表），而��试图通过添加一
	些奇特的邮件头�解决这个问题，人们�会喜欢的。
	
	记��留你所回�内容的上下文和�头。在你回�邮件的顶部�留“���说到……�
	这几行。将你的评论加在被引用的段�之间而��放在邮件的顶部。
	
	如果你在邮件中附带补�，请确认它们是�以直接阅读的纯文本（如
	Documentation/SubmittingPatches文档中所述）。内核开�者们�希望�到附件
	或者被压缩了的补�。�有这样�能��他们�以直接评论你的�行代�。请确�
	你使用的邮件��程��会修改空格和制表符。一个防范性的测试方法是先将邮件
	��给自己，然�自己�试是��以顺利地打上收到的补�。如果测试��功，请
	调整或者更�你的邮件��程�直到它正确工作为止。
	
	总而言之，请尊�其他的邮件列表订阅者。
	
	
	�内核社区�作
	----------------
	
	内核社区的目标就是�供尽善尽美的内核。所以当你�交补�期望被接�进内核的
	时候，它的技术价值以�其他方�都将被评审。那么你�能会得到什么呢？
	  - 批评
	  - 评论
	  - �求修改
	  - �求�明修改的必�性
	  - 沉默
	
	�记�，这些是把补�放进内核的正常情况。你必须学会��对补�的批评和评论，
	从技术层�评估它们，然��么�写你的补��么简明扼�地论�修改是�必�
	的。如果你�的邮件没有得到任何回应，请过几天��试一次，因为有时信件会湮
	没在茫茫信海中。
	
	你�应该�的事情：
	  - 期望自己的补���任何质疑就直接被接�
	  - 翻脸
	  - 忽略别人的评论
	  - 没有按照别人的�求�任何修改就�新�交
	
	在一个努力追寻最好技术方案的社区里，对于一个补�有多少好处总会有��的�
	解。你必须�抱��作的�度，愿�改�自己的观点�适应内核的风格。或者至少
	愿�去�明你的想法是有价值的。记�，犯错误是�许的，��你愿���正确的
	方案去努力。
	
	如果你的第一个补���的是一堆修改建议，这是很正常的。这并�代表你的补�
	�会被接�，也��味�有人和你作对。你�需�改正所有�出的问题然��新�
	�你的补�。
	
	内核社区和公�文化的差异
	------------------------
	
	内核社区的工作模��大多数传统公�开�队�的工作模�并�相�。下�这些例
	�，�以帮助你���些�能�生问题：
	  用这些�介�你的修改�案会有好处：
	    - 它�时解决了多个问题
	    - 它删除了2000行代�
	    - 这是补�，它已�解释了我想�说明的
	    - 我在5���的体系结构上测试过它……
	    - 这是一系列�补�用�……
	    - 这个修改�高了普通机器的性能……
	
	  应该��如下的说法：
	    - 我们在AIX/ptx/Solaris就是这么�的，所以这么�肯定是好的……
	    - 我�这行已�20年了，所以……
	    - 为了我们公�赚钱考虑必须这么�
	    - 这是我们的�业产�线所需�的
	    - 这里是�述我观点的1000页设计文档
	    - 这是一个5000行的补�用�……
	    - 我�写了现在乱七八糟的代�，这就是……
	    - 我被规定了最�期�，所以这个补�需�立刻被接�
	
	�外一个内核社区与大部分传统公�的软件开�队���的地方是无法�对�地交
	�。使用电�邮件和IRC�天工具�为主�沟通工具的一个好处是性别和��歧视
	将会更少。Linux内核的工作环境更能接�妇女和少数�群，因为�个人在别人眼
	里�是一个邮件地�。国际化也帮助了公平的实现，因为你无法通过姓��判断人
	的性别。男人有�能��丽，女人也有�能�王刚。大多数在Linux内核上工作过
	并表达过看法的女性对在linux上工作的�历都给出了正�的评价。
	
	对于一些�习惯使用英语的人�说，语言�能是一个引起问题的障�。在邮件列表
	中�正确地表达想法必需良好地掌�语言，所以建议你在��邮件之�最好检查一
	下英文写得是�正确。
	
	
	拆分修改
	--------
	
	Linux内核社区并�喜欢一下接收大段的代�。修改需�被�当地介��讨论并且
	拆分�独立的�段。这几乎完全和公�中的习惯背�而驰。你的想法应该在开�最
	开始的阶段就让大家知�，这样你就�以�时获得对你正在进行的开�的�馈。这
	样也会让社区觉得你是在和他们�作，而�是仅仅把他们当作倾销新功能的对象。
	无论如何，你��一次性地�邮件列表��50�信，你的补��列应该永远用�到
	这么多。
	
	将补�拆开的原因如下：
	
	1) �的补�更有�能被接�，因为它们�需�太多的时间和精力去验�其正确性。
	   一个5行的补�，�能在维护者看了一眼以�就会被接�。而500行的补�则
	   需�数个�时�审查其正确性（所需时间�补�大�增加大约呈指数级增长）。
	
	   当出了问题的时候，�的补�也会让调试�得�常容易。一个一个补�地回溯
	   将会比仔细剖�一个被打上的大补�（这个补�破�了其他东西）容易得多。
	
	2）�光���的补�很��，在�交之��新编排�化简（或者仅仅�新