You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6
This can be broken down into these major areas: - Documentation updates (language translations and fixes, as well as kobject and kset documenatation updates.) - major kset/kobject/ktype rework and fixes. This cleans up the kset and kobject and ktype relationship and architecture, making sense of things now, and good documenation and samples are provided for others to use. Also the attributes for kobjects are much easier to handle now. This cleaned up a LOT of code all through the kernel, making kobjects easier to use if you want to. - struct bus_type has been reworked to now handle the lifetime rules properly, as the kobject is properly dynamic. - struct driver has also been reworked, and now the lifetime issues are resolved. - the block subsystem has been converted to use struct device now, and not "raw" kobjects. This patch has been in the -mm tree for over a year now, and finally all the issues are worked out with it. Older distros now properly work with new kernels, and no userspace updates are needed at all. - nozomi driver is added. This has also been in -mm for a long time, and many people have asked for it to go in. It is now in good enough shape to do so. - lots of class_device conversions to use struct device instead. The tree is almost all cleaned up now, only SCSI and IB is the remaining code to fix up... * git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6: (196 commits) Driver core: coding style fixes Kobject: fix coding style issues in kobject c files Kobject: fix coding style issues in kobject.h Driver core: fix coding style issues in device.h spi: use class iteration api scsi: use class iteration api rtc: use class iteration api power supply : use class iteration api ieee1394: use class iteration api Driver Core: add class iteration api Driver core: Cleanup get_device_parent() in device_add() and device_move() UIO: constify function pointer tables Driver Core: constify the name passed to platform_device_register_simple driver core: fix build with SYSFS=n sysfs: make SYSFS_DEPRECATED depend on SYSFS Driver core: use LIST_HEAD instead of call to INIT_LIST_HEAD in __init kobject: add sample code for how to use ksets/ktypes/kobjects kobject: add sample code for how to use kobjects in a simple manner. kobject: update the kobject/kset documentation kobject: remove old, outdated documentation. ...
This commit is contained in:
Linus Torvalds
+335
-238
File diff suppressed because it is too large
Load Diff
@@ -17,9 +17,9 @@ The User Interface
|
||||
------------------
|
||||
The Linux Plug and Play user interface provides a means to activate PnP devices
|
||||
for legacy and user level drivers that do not support Linux Plug and Play. The
|
||||
user interface is integrated into driverfs.
|
||||
user interface is integrated into sysfs.
|
||||
|
||||
In addition to the standard driverfs file the following are created in each
|
||||
In addition to the standard sysfs file the following are created in each
|
||||
device's directory:
|
||||
id - displays a list of support EISA IDs
|
||||
options - displays possible resource configurations
|
||||
|
||||
@@ -133,7 +133,7 @@ During its startup the Linux/390 system checks for peripheral devices. Each
|
||||
of those devices is uniquely defined by a so called subchannel by the ESA/390
|
||||
channel subsystem. While the subchannel numbers are system generated, each
|
||||
subchannel also takes a user defined attribute, the so called device number.
|
||||
Both subchannel number and device number cannot exceed 65535. During driverfs
|
||||
Both subchannel number and device number cannot exceed 65535. During sysfs
|
||||
initialisation, the information about control unit type and device types that
|
||||
imply specific I/O commands (channel command words - CCWs) in order to operate
|
||||
the device are gathered. Device drivers can retrieve this set of hardware
|
||||
|
||||
@@ -1021,7 +1021,7 @@ void read_slab_dir(void)
|
||||
char *t;
|
||||
int count;
|
||||
|
||||
if (chdir("/sys/slab"))
|
||||
if (chdir("/sys/kernel/slab"))
|
||||
fatal("SYSFS support for SLUB not active\n");
|
||||
|
||||
dir = opendir(".");
|
||||
|
||||
@@ -63,7 +63,7 @@ In case you forgot to enable debugging on the kernel command line: It is
|
||||
possible to enable debugging manually when the kernel is up. Look at the
|
||||
contents of:
|
||||
|
||||
/sys/slab/<slab name>/
|
||||
/sys/kernel/slab/<slab name>/
|
||||
|
||||
Look at the writable files. Writing 1 to them will enable the
|
||||
corresponding debug option. All options can be set on a slab that does
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,10 +1,10 @@
|
||||
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 problem
|
||||
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 there is problem with translation.
|
||||
help. Contact the Chinese maintainer if this translation is outdated
|
||||
or if there is a problem with the translation.
|
||||
|
||||
Maintainer: Greg Kroah-Hartman <greg@kroah.com>
|
||||
Chinese maintainer: Li Yang <leoli@freescale.com>
|
||||
@@ -85,7 +85,7 @@ Linux内核源代码都是在GPL（通用公共许可证）的保护下发布的
|
||||
Linux内核代码中包含有大量的文档。这些文档对于学习如何与内核社区互动有着
|
||||
不可估量的价值。当一个新的功能被加入内核，最好把解释如何使用这个功能的文
|
||||
档也放进内核。当内核的改动导致面向用户空间的接口发生变化时，最好将相关信
|
||||
息或手册页(manpages)的补丁发到mtk-manpages@gmx.net，以向手册页(manpages)
|
||||
息或手册页(manpages)的补丁发到mtk.manpages@gmail.com，以向手册页(manpages)
|
||||
的维护者解释这些变化。
|
||||
|
||||
以下是内核代码中需要阅读的文档：
|
||||
@@ -218,6 +218,8 @@ kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开发遵循
|
||||
时，一个新的-rc版本就会被发布。计划是每周都发布新的-rc版本。
|
||||
- 这个过程一直持续下去直到内核被认为达到足够稳定的状态，持续时间大概是
|
||||
6个星期。
|
||||
- 以下地址跟踪了在每个-rc发布中发现的退步列表：
|
||||
http://kernelnewbies.org/known_regressions
|
||||
|
||||
关于内核发布，值得一提的是Andrew Morton在linux-kernel邮件列表中如是说：
|
||||
“没有人知道新内核何时会被发布，因为发布是根据已知bug的情况来决定
|
||||
|
||||
@@ -0,0 +1,168 @@
|
||||
Chinese translated version of Documentation/SubmittingDrivers
|
||||
|
||||
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: Li Yang <leo@zh-kernel.org>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/SubmittingDrivers 的中文翻译
|
||||
|
||||
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
|
||||
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
|
||||
译存在问题，请联系中文版维护者。
|
||||
|
||||
中文版维护者： 李阳 Li Yang <leo@zh-kernel.org>
|
||||
中文版翻译者： 李阳 Li Yang <leo@zh-kernel.org>
|
||||
中文版校译者： 陈琦 Maggie Chen <chenqi@beyondsoft.com>
|
||||
王聪 Wang Cong <xiyou.wangcong@gmail.com>
|
||||
张巍 Zhang Wei <Wei.Zhang@freescale.com>
|
||||
|
||||
以下为正文
|
||||
---------------------------------------------------------------------
|
||||
|
||||
如何向 Linux 内核提交驱动程序
|
||||
-----------------------------
|
||||
|
||||
这篇文档将会解释如何向不同的内核源码树提交设备驱动程序。请注意，如果你感
|
||||
兴趣的是显卡驱动程序，你也许应该访问 XFree86 项目(http://www.xfree86.org/)
|
||||
和／或 X.org 项目 (http://x.org)。
|
||||
|
||||
另请参阅 Documentation/SubmittingPatches 文档。
|
||||
|
||||
|
||||
分配设备号
|
||||
----------
|
||||
|
||||
块设备和字符设备的主设备号与从设备号是由 Linux 命名编号分配权威 LANANA（
|
||||
现在是 Torben Mathiasen）负责分配。申请的网址是 http://www.lanana.org/。
|
||||
即使不准备提交到主流内核的设备驱动也需要在这里分配设备号。有关详细信息，
|
||||
请参阅 Documentation/devices.txt。
|
||||
|
||||
如果你使用的不是已经分配的设备号，那么当你提交设备驱动的时候，它将会被强
|
||||
制分配一个新的设备号，即便这个设备号和你之前发给客户的截然不同。
|
||||
|
||||
设备驱动的提交对象
|
||||
------------------
|
||||
|
||||
Linux 2.0:
|
||||
此内核源码树不接受新的驱动程序。
|
||||
|
||||
Linux 2.2:
|
||||
此内核源码树不接受新的驱动程序。
|
||||
|
||||
Linux 2.4:
|
||||
如果所属的代码领域在内核的 MAINTAINERS 文件中列有一个总维护者，
|
||||
那么请将驱动程序提交给他。如果此维护者没有回应或者你找不到恰当的
|
||||
维护者，那么请联系 Willy Tarreau <w@1wt.eu>。
|
||||
|
||||
Linux 2.6:
|
||||
除了遵循和 2.4 版内核同样的规则外，你还需要在 linux-kernel 邮件
|
||||
列表上跟踪最新的 API 变化。向 Linux 2.6 内核提交驱动的顶级联系人
|
||||
是 Andrew Morton <akpm@osdl.org>。
|
||||
|
||||
决定设备驱动能否被接受的条件
|
||||
----------------------------
|
||||
|
||||
许可： 代码必须使用 GNU 通用公开许可证 (GPL) 提交给 Linux，但是
|
||||
我们并不要求 GPL 是唯一的许可。你或许会希望同时使用多种
|
||||
许可证发布，如果希望驱动程序可以被其他开源社区（比如BSD）
|
||||
使用。请参考 include/linux/module.h 文件中所列出的可被
|
||||
接受共存的许可。
|
||||
|
||||
版权： 版权所有者必须同意使用 GPL 许可。最好提交者和版权所有者
|
||||
是相同个人或实体。否则，必需列出授权使用 GPL 的版权所有
|
||||
人或实体，以备验证之需。
|
||||
|
||||
接口： 如果你的驱动程序使用现成的接口并且和其他同类的驱动程序行
|
||||
为相似，而不是去发明无谓的新接口，那么它将会更容易被接受。
|
||||
如果你需要一个 Linux 和 NT 的通用驱动接口，那么请在用
|
||||
户空间实现它。
|
||||
|
||||
代码： 请使用 Documentation/CodingStyle 中所描述的 Linux 代码风
|
||||
格。如果你的某些代码段（例如那些与 Windows 驱动程序包共
|
||||
享的代码段）需要使用其他格式，而你却只希望维护一份代码，
|
||||
那么请将它们很好地区分出来，并且注明原因。
|
||||
|
||||
可移植性： 请注意，指针并不永远是 32 位的，不是所有的计算机都使用小
|
||||
尾模式 (little endian) 存储数据，不是所有的人都拥有浮点
|
||||
单元，不要随便在你的驱动程序里嵌入 x86 汇编指令。只能在
|
||||
x86 上运行的驱动程序一般是不受欢迎的。虽然你可能只有 x86
|
||||
硬件，很难测试驱动程序在其他平台上是否可用，但是确保代码
|
||||
可以被轻松地移植却是很简单的。
|
||||
|
||||
清晰度： 做到所有人都能修补这个驱动程序将会很有好处，因为这样你将
|
||||
会直接收到修复的补丁而不是 bug 报告。如果你提交一个试图
|
||||
隐藏硬件工作机理的驱动程序，那么它将会被扔进废纸篓。
|
||||
|
||||
电源管理： 因为 Linux 正在被很多移动设备和桌面系统使用，所以你的驱
|
||||
动程序也很有可能被使用在这些设备上。它应该支持最基本的电
|
||||
源管理，即在需要的情况下实现系统级休眠和唤醒要用到的
|
||||
.suspend 和 .resume 函数。你应该检查你的驱动程序是否能正
|
||||
确地处理休眠与唤醒，如果实在无法确认，请至少把 .suspend
|
||||
函数定义成返回 -ENOSYS（功能未实现）错误。你还应该尝试确
|
||||
保你的驱动在什么都不干的情况下将耗电降到最低。要获得驱动
|
||||
程序测试的指导，请参阅
|
||||
Documentation/power/drivers-testing.txt。有关驱动程序电
|
||||
源管理问题相对全面的概述，请参阅
|
||||
Documentation/power/devices.txt。
|
||||
|
||||
管理： 如果一个驱动程序的作者还在进行有效的维护，那么通常除了那
|
||||
些明显正确且不需要任何检查的补丁以外，其他所有的补丁都会
|
||||
被转发给作者。如果你希望成为驱动程序的联系人和更新者，最
|
||||
好在代码注释中写明并且在 MAINTAINERS 文件中加入这个驱动
|
||||
程序的条目。
|
||||
|
||||
不影响设备驱动能否被接受的条件
|
||||
------------------------------
|
||||
|
||||
供应商： 由硬件供应商来维护驱动程序通常是一件好事。不过，如果源码
|
||||
树里已经有其他人提供了可稳定工作的驱动程序，那么请不要期
|
||||
望“我是供应商”会成为内核改用你的驱动程序的理由。理想的情
|
||||
况是：供应商与现有驱动程序的作者合作，构建一个统一完美的
|
||||
驱动程序。
|
||||
|
||||
作者： 驱动程序是由大的 Linux 公司研发还是由你个人编写，并不影
|
||||
响其是否能被内核接受。没有人对内核源码树享有特权。只要你
|
||||
充分了解内核社区，你就会发现这一点。
|
||||
|
||||
|
||||
资源列表
|
||||
--------
|
||||
|
||||
Linux 内核主源码树：
|
||||
ftp.??.kernel.org:/pub/linux/kernel/...
|
||||
?? == 你的国家代码，例如 "cn"、"us"、"uk"、"fr" 等等
|
||||
|
||||
Linux 内核邮件列表：
|
||||
linux-kernel@vger.kernel.org
|
||||
[可通过向majordomo@vger.kernel.org发邮件来订阅]
|
||||
|
||||
Linux 设备驱动程序，第三版（探讨 2.6.10 版内核）：
|
||||
http://lwn.net/Kernel/LDD3/ （免费版）
|
||||
|
||||
LWN.net:
|
||||
每周内核开发活动摘要 - http://lwn.net/
|
||||
2.6 版中 API 的变更：
|
||||
http://lwn.net/Articles/2.6-kernel-api/
|
||||
将旧版内核的驱动程序移植到 2.6 版：
|
||||
http://lwn.net/Articles/driver-porting/
|
||||
|
||||
KernelTrap：
|
||||
Linux 内核的最新动态以及开发者访谈
|
||||
http://kerneltrap.org/
|
||||
|
||||
内核新手(KernelNewbies):
|
||||
为新的内核开发者提供文档和帮助
|
||||
http://kernelnewbies.org/
|
||||
|
||||
Linux USB项目：
|
||||
http://www.linux-usb.org/
|
||||
|
||||
写内核驱动的“不要”（Arjan van de Ven著）:
|
||||
http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf
|
||||
|
||||
内核清洁工 (Kernel Janitor):
|
||||
http://janitor.kernelnewbies.org/
|
||||
@@ -0,0 +1,416 @@
|
||||
Chinese translated version of Documentation/SubmittingPatches
|
||||
|
||||
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: TripleX Chung <triplex@zh-kernel.org>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/SubmittingPatches 的中文翻译
|
||||
|
||||
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
|
||||
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
|
||||
译存在问题，请联系中文版维护者。
|
||||
|
||||
中文版维护者： 钟宇 TripleX Chung <triplex@zh-kernel.org>
|
||||
中文版翻译者： 钟宇 TripleX Chung <triplex@zh-kernel.org>
|
||||
中文版校译者： 李阳 Li Yang <leo@zh-kernel.org>
|
||||
王聪 Wang Cong <xiyou.wangcong@gmail.com>
|
||||
|
||||
以下为正文
|
||||
---------------------------------------------------------------------
|
||||
|
||||
如何让你的改动进入内核
|
||||
或者
|
||||
获得亲爱的 Linus Torvalds 的关注和处理
|
||||
----------------------------------
|
||||
|
||||
对于想要将改动提交到 Linux 内核的个人或者公司来说，如果不熟悉“规矩”，
|
||||
提交的流程会让人畏惧。本文档收集了一系列建议，这些建议可以大大的提高你
|
||||
的改动被接受的机会。
|
||||
阅读 Documentation/SubmitChecklist 来获得在提交代码前需要检查的项目的列
|
||||
表。如果你在提交一个驱动程序，那么同时阅读一下
|
||||
Documentation/SubmittingDrivers 。
|
||||
|
||||
|
||||
--------------------------
|
||||
第一节 - 创建并发送你的改动
|
||||
--------------------------
|
||||
|
||||
1) "diff -up"
|
||||
-----------
|
||||
|
||||
使用 "diff -up" 或者 "diff -uprN" 来创建补丁。
|
||||
|
||||
所有内核的改动，都是以补丁的形式呈现的，补丁由 diff(1) 生成。创建补丁的
|
||||
时候，要确认它是以 "unified diff" 格式创建的，这种格式由 diff(1) 的 '-u'
|
||||
参数生成。而且，请使用 '-p' 参数，那样会显示每个改动所在的C函数，使得
|
||||
产生的补丁容易读得多。补丁应该基于内核源代码树的根目录，而不是里边的任
|
||||
何子目录。
|
||||
为一个单独的文件创建补丁，一般来说这样做就够了：
|
||||
|
||||
SRCTREE= linux-2.6
|
||||
MYFILE= drivers/net/mydriver.c
|
||||
|
||||
cd $SRCTREE
|
||||
cp $MYFILE $MYFILE.orig
|
||||
vi $MYFILE # make your change
|
||||
cd ..
|
||||
diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
|
||||
|
||||
为多个文件创建补丁，你可以解开一个没有修改过的内核源代码树，然后和你自
|
||||
己的代码树之间做 diff 。例如：
|
||||
|
||||
MYSRC= /devel/linux-2.6
|
||||
|
||||
tar xvfz linux-2.6.12.tar.gz
|
||||
mv linux-2.6.12 linux-2.6.12-vanilla
|
||||
diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
|
||||
linux-2.6.12-vanilla $MYSRC > /tmp/patch
|
||||
|
||||
"dontdiff" 是内核在编译的时候产生的文件的列表，列表中的文件在 diff(1)
|
||||
产生的补丁里会被跳过。"dontdiff" 文件被包含在2.6.12和之后版本的内核源代
|
||||
码树中。对于更早的内核版本，你可以从
|
||||
<http://www.xenotime.net/linux/doc/dontdiff> 获取它。
|
||||
确定你的补丁里没有包含任何不属于这次补丁提交的额外文件。记得在用diff(1)
|
||||
生成补丁之后，审阅一次补丁，以确保准确。
|
||||
如果你的改动很散乱，你应该研究一下如何将补丁分割成独立的部分，将改动分
|
||||
割成一系列合乎逻辑的步骤。这样更容易让其他内核开发者审核，如果你想你的
|
||||
补丁被接受，这是很重要的。下面这些脚本能够帮助你做这件事情：
|
||||
Quilt:
|
||||
http://savannah.nongnu.org/projects/quilt
|
||||
|
||||
Andrew Morton 的补丁脚本:
|
||||
http://www.zip.com.au/~akpm/linux/patches/
|
||||
作为这些脚本的替代，quilt 是值得推荐的补丁管理工具(看上面的链接)。
|
||||
|
||||
2)描述你的改动。
|
||||
描述你的改动包含的技术细节。
|
||||
|
||||
要多具体就写多具体。最糟糕的描述可能是像下面这些语句：“更新了某驱动程
|
||||
序”，“修正了某驱动程序的bug”，或者“这个补丁包含了某子系统的修改，请
|
||||
使用。”
|
||||
|
||||
如果你的描述开始变长，这表示你也许需要拆分你的补丁了，请看第3小节，
|
||||
继续。
|
||||
|
||||
3)拆分你的改动
|
||||
|
||||
将改动拆分，逻辑类似的放到同一个补丁文件里。
|
||||
|
||||
例如，如果你的改动里同时有bug修正和性能优化，那么把这些改动才分到两个或
|
||||
者更多的补丁文件中。如果你的改动包含对API的修改，并且修改了驱动程序来适
|
||||
应这些新的API，那么把这些修改分成两个补丁。
|
||||
|
||||
另一方面，如果你将一个单独的改动做成多个补丁文件，那么将它们合并成一个
|
||||
单独的补丁文件。这样一个逻辑上单独的改动只被包含在一个补丁文件里。
|
||||
|
||||
如果有一个补丁依赖另外一个补丁来完成它的改动，那没问题。简单的在你的补
|
||||
丁描述里指出“这个补丁依赖某补丁”就好了。
|
||||
|
||||
如果你不能将补丁浓缩成更少的文件，那么每次大约发送出15个，然后等待审查
|
||||
和整合。
|
||||
|
||||
4)选择 e-mail 的收件人
|
||||
|
||||
看一遍 MAINTAINERS 文件和源代码，看看你所的改动所在的内核子系统有没有指
|
||||
定的维护者。如果有，给他们发e-mail。
|
||||
|
||||
如果没有找到维护者，或者维护者没有反馈，将你的补丁发送到内核开发者主邮
|
||||
件列表 linux-kernel@vger.kernel.org。大部分的内核开发者都跟踪这个邮件列
|
||||
表，可以评价你的改动。
|
||||
|
||||
每次不要发送超过15个补丁到 vger 邮件列表！！！
|
||||
|
||||
Linus Torvalds 是决定改动能否进入 Linux 内核的最终裁决者。他的 e-mail
|
||||
地址是 <torvalds@linux-foundation.org> 。他收到的 e-mail 很多，所以一般
|
||||
的说，最好别给他发 e-mail。
|
||||
|
||||
那些修正bug，“显而易见”的修改或者是类似的只需要很少讨论的补丁可以直接
|
||||
发送或者CC给Linus。那些需要讨论或者没有很清楚的好处的补丁，一般先发送到
|
||||
linux-kernel邮件列表。只有当补丁被讨论得差不多了，才提交给Linus。
|
||||
|
||||
5)选择CC( e-mail 抄送)列表
|
||||
|
||||
除非你有理由不这样做，否则CC linux-kernel@vger.kernel.org。
|
||||
|
||||
除了 Linus 之外，其他内核开发者也需要注意到你的改动，这样他们才能评论你
|
||||
的改动并提供代码审查和建议。linux-kernel 是 Linux 内核开发者主邮件列表
|
||||
。其它的邮件列表为特定的子系统提供服务，比如 USB，framebuffer 设备，虚
|
||||
拟文件系统，SCSI 子系统，等等。查看 MAINTAINERS 文件来获得和你的改动有
|
||||
关的邮件列表。
|
||||
|
||||
Majordomo lists of VGER.KERNEL.ORG at:
|
||||
<http://vger.kernel.org/vger-lists.html>
|
||||
|
||||
如果改动影响了用户空间和内核之间的接口，请给 MAN-PAGES 的维护者（列在
|
||||
MAITAINERS 文件里的）发送一个手册页（man-pages）补丁，或者至少通知一下改
|
||||
变，让一些信息有途径进入手册页。
|
||||
|
||||
即使在第四步的时候，维护者没有作出回应，也要确认在修改他们的代码的时候
|
||||
，一直将维护者拷贝到CC列表中。
|
||||
|
||||
对于小的补丁，你也许会CC到 Adrian Bunk 管理的搜集琐碎补丁的邮件列表
|
||||
(Trivial Patch Monkey)trivial@kernel.org，那里专门收集琐碎的补丁。下面这样
|
||||
的补丁会被看作“琐碎的”补丁：
|
||||
文档的拼写修正。
|
||||
修正会影响到 grep(1) 的拼写。
|
||||
警告信息修正(频繁的打印无用的警告是不好的。)
|
||||
编译错误修正（代码逻辑的确是对的，只是编译有问题。）
|
||||
运行时修正（只要真的修正了错误。）
|
||||
移除使用了被废弃的函数/宏的代码(例如 check_region。)
|
||||
联系方式和文档修正。
|
||||
用可移植的代码替换不可移植的代码（即使在体系结构相关的代码中，既然有
|
||||
人拷贝，只要它是琐碎的）
|
||||
任何文件的作者/维护者对该文件的改动（例如 patch monkey 在重传模式下）
|
||||
|
||||
URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/>
|
||||
|
||||
(译注，关于“琐碎补丁”的一些说明：因为原文的这一部分写得比较简单，所以不得不
|
||||
违例写一下译注。"trivial"这个英文单词的本意是“琐碎的，不重要的。”但是在这里
|
||||
有稍微有一些变化，例如对一些明显的NULL指针的修正，属于运行时修正，会被归类
|
||||
到琐碎补丁里。虽然NULL指针的修正很重要，但是这样的修正往往很小而且很容易得到
|
||||
检验，所以也被归入琐碎补丁。琐碎补丁更精确的归类应该是
|
||||
“simple, localized & easy to verify”，也就是说简单的，局部的和易于检验的。
|
||||
trivial@kernel.org邮件列表的目的是针对这样的补丁，为提交者提供一个中心，来
|
||||
降低提交的门槛。)
|
||||
|
||||
6)没有 MIME 编码，没有链接，没有压缩，没有附件，只有纯文本。
|
||||
|
||||
Linus 和其他的内核开发者需要阅读和评论你提交的改动。对于内核开发者来说
|
||||
，可以“引用”你的改动很重要，使用一般的 e-mail 工具，他们就可以在你的
|
||||
代码的任何位置添加评论。
|
||||
|
||||
因为这个原因，所有的提交的补丁都是 e-mail 中“内嵌”的。
|
||||
警告：如果你使用剪切-粘贴你的补丁，小心你的编辑器的自动换行功能破坏你的
|
||||
补丁。
|
||||
|
||||
不要将补丁作为 MIME 编码的附件，不管是否压缩。很多流行的 e-mail 软件不
|
||||
是任何时候都将 MIME 编码的附件当作纯文本发送的，这会使得别人无法在你的
|
||||
代码中加评论。另外，MIME 编码的附件会让 Linus 多花一点时间来处理，这就
|
||||
降低了你的改动被接受的可能性。
|
||||
|
||||
警告：一些邮件软件，比如 Mozilla 会将你的信息以如下格式发送：
|
||||
---- 邮件头 ----
|
||||
Content-Type: text/plain; charset=us-ascii; format=flowed
|
||||
---- 邮件头 ----
|
||||
问题在于 “format=flowed” 会让接收端的某些邮件软件将邮件中的制表符替换
|
||||
成空格以及做一些类似的替换。这样，你发送的时候看起来没问题的补丁就被破
|
||||
坏了。
|
||||
|
||||
要修正这个问题，只需要将你的 mozilla 的 defaults/pref/mailnews.js 文件
|
||||
里的
|
||||
pref("mailnews.send_plaintext_flowed", false); // RFC 2646=======
|
||||
修改成
|
||||
pref("mailnews.display.disable_format_flowed_support", true);
|
||||
就可以了。
|
||||
|
||||
7) e-mail 的大小
|
||||
|
||||
给 Linus 发送补丁的时候，永远按照第6小节说的做。
|
||||
|
||||
大的改动对邮件列表不合适，对某些维护者也不合适。如果你的补丁，在不压缩
|
||||
的情况下，超过了40kB，那么你最好将补丁放在一个能通过 internet 访问的服
|
||||
务器上，然后用指向你的补丁的 URL 替代。
|
||||
|
||||
8) 指出你的内核版本
|
||||
|
||||
在标题和在补丁的描述中，指出补丁对应的内核的版本，是很重要的。
|
||||
|
||||
如果补丁不能干净的在最新版本的内核上打上，Linus 是不会接受它的。
|
||||
|
||||
9) 不要气馁，继续提交。
|
||||
|
||||
当你提交了改动以后，耐心地等待。如果 Linus 喜欢你的改动并且同意它，那么
|
||||
它将在下一个内核发布版本中出现。
|
||||
|
||||
然而，如果你的改动没有出现在下一个版本的内核中，可能有若干原因。减少那
|
||||
些原因，修正错误，重新提交更新后的改动，是你自己的工作。
|
||||
|
||||
Linus不给出任何评论就“丢弃”你的补丁是常见的事情。在系统中这样的事情很
|
||||
平常。如果他没有接受你的补丁，也许是由于以下原本：
|
||||
* 你的补丁不能在最新版本的内核上干净的打上。
|
||||
* 你的补丁在 linux-kernel 邮件列表中没有得到充分的讨论。
|
||||
* 风格问题（参照第2小节）
|
||||
* 邮件格式问题（重读本节）
|
||||
* 你的改动有技术问题。
|
||||
* 他收到了成吨的 e-mail，而你的在混乱中丢失了。
|
||||
* 你让人为难。
|
||||
|
||||
有疑问的时候，在 linux-kernel 邮件列表上请求评论。
|
||||
|
||||
10) 在标题上加上 PATCH 的字样
|
||||
|
||||
Linus 和 linux-kernel 邮件列表的 e-mail 流量都很高，一个通常的约定是标
|
||||
题行以 [PATCH] 开头。这样可以让 Linus 和其他内核开发人员可以从 e-mail
|
||||
的讨论中很轻易的将补丁分辨出来。
|
||||
|
||||
11）为你的工作签名
|
||||
|
||||
为了加强对谁做了何事的追踪，尤其是对那些透过好几层的维护者的补丁，我们
|
||||
建议在发送出去的补丁上加一个 “sign-off” 的过程。
|
||||
|
||||
"sign-off" 是在补丁的注释的最后的简单的一行文字，认证你编写了它或者其他
|
||||
人有权力将它作为开放源代码的补丁传递。规则很简单：如果你能认证如下信息
|
||||
：
|
||||
开发者来源证书 1.1
|
||||
对于本项目的贡献，我认证如下信息：
|
||||
（a）这些贡献是完全或者部分的由我创建，我有权利以文件中指出
|
||||
的开放源代码许可证提交它；或者
|
||||
（b）这些贡献基于以前的工作，据我所知，这些以前的工作受恰当的开放
|
||||
源代码许可证保护，而且，根据许可证，我有权提交修改后的贡献，
|
||||
无论是完全还是部分由我创造，这些贡献都使用同一个开放源代码许可证
|
||||
（除非我被允许用其它的许可证），正如文件中指出的；或者
|
||||
（c）这些贡献由认证（a），（b）或者（c）的人直接提供给我，而
|
||||
且我没有修改它。
|
||||
（d）我理解并同意这个项目和贡献是公开的，贡献的记录（包括我
|
||||
一起提交的个人记录，包括 sign-off ）被永久维护并且可以和这个项目
|
||||
或者开放源代码的许可证同步地再发行。
|
||||
那么加入这样一行：
|
||||
Signed-off-by: Random J Developer <random@developer.example.org>
|
||||
|
||||
使用你的真名（抱歉，不能使用假名或者匿名。）
|
||||
|
||||
有人在最后加上标签。现在这些东西会被忽略，但是你可以这样做，来标记公司
|
||||
内部的过程，或者只是指出关于 sign-off 的一些特殊细节。
|
||||
|
||||
12）标准补丁格式
|
||||
|
||||
标准的补丁，标题行是：
|
||||
Subject: [PATCH 001/123] 子系统:一句话概述
|
||||
|
||||
标准补丁的信体存在如下部分：
|
||||
|
||||
- 一个 "from" 行指出补丁作者。
|
||||
|
||||
- 一个空行
|
||||
|
||||
- 说明的主体，这些说明文字会被拷贝到描述该补丁的永久改动记录里。
|
||||
|
||||
- 一个由"---"构成的标记行
|
||||
|
||||
- 不合适放到改动记录里的额外的注解。
|
||||
|
||||
- 补丁本身（diff 输出）
|
||||
|
||||
标题行的格式，使得对标题行按字母序排序非常的容易 - 很多 e-mail 客户端都
|
||||
可以支持 - 因为序列号是用零填充的，所以按数字排序和按字母排序是一样的。
|
||||
|
||||
e-mail 标题中的“子系统”标识哪个内核子系统将被打补丁。
|
||||
|
||||
e-mail 标题中的“一句话概述”扼要的描述 e-mail 中的补丁。“一句话概述”
|
||||
不应该是一个文件名。对于一个补丁系列（“补丁系列”指一系列的多个相关补
|
||||
丁），不要对每个补丁都使用同样的“一句话概述”。
|
||||
|
||||
记住 e-mail 的“一句话概述”会成为该补丁的全局唯一标识。它会蔓延到 git
|
||||
的改动记录里。然后“一句话概述”会被用在开发者的讨论里，用来指代这个补
|
||||
丁。用户将希望通过 google 来搜索"一句话概述"来找到那些讨论这个补丁的文
|
||||
章。
|
||||
|
||||
一些标题的例子：
|
||||
|
||||
Subject: [patch 2/5] ext2: improve scalability of bitmap searching
|
||||
Subject: [PATCHv2 001/207] x86: fix eflags tracking
|
||||
|
||||
"from" 行是信体里的最上面一行，具有如下格式：
|
||||
From: Original Author <author@example.com>
|
||||
|
||||
"from" 行指明在永久改动日志里，谁会被确认为作者。如果没有 "from" 行，那
|
||||
么邮件头里的 "From: " 行会被用来决定改动日志中的作者。
|
||||
|
||||
说明的主题将会被提交到永久的源代码改动日志里，因此对那些早已经不记得和
|
||||
这个补丁相关的讨论细节的有能力的读者来说，是有意义的。
|
||||
|
||||
"---" 标记行对于补丁处理工具要找到哪里是改动日志信息的结束，是不可缺少
|
||||
的。
|
||||
|
||||
对于 "---" 标记之后的额外注解，一个好的用途就是用来写 diffstat，用来显
|
||||
示修改了什么文件和每个文件都增加和删除了多少行。diffstat 对于比较大的补
|
||||
丁特别有用。其余那些只是和时刻或者开发者相关的注解，不合适放到永久的改
|
||||
动日志里的，也应该放这里。
|
||||
使用 diffstat的选项 "-p 1 -w 70" 这样文件名就会从内核源代码树的目录开始
|
||||
，不会占用太宽的空间（很容易适合80列的宽度，也许会有一些缩进。）
|
||||
|
||||
在后面的参考资料中能看到适当的补丁格式的更多细节。
|
||||
|
||||
-------------------------------
|
||||
第二节 提示，建议和诀窍
|
||||
-------------------------------
|
||||
|
||||
本节包含很多和提交到内核的代码有关的通常的"规则"。事情永远有例外...但是
|
||||
你必须真的有好的理由这样做。你可以把本节叫做Linus的计算机科学入门课。
|
||||
|
||||
1) 读 Document/CodingStyle
|
||||
|
||||
Nuff 说过，如果你的代码和这个偏离太多，那么它有可能会被拒绝，没有更多的
|
||||
审查，没有更多的评价。
|
||||
|
||||
2) #ifdef 是丑陋的
|
||||
混杂了 ifdef 的代码难以阅读和维护。别这样做。作为替代，将你的 ifdef 放
|
||||
在头文件里，有条件地定义 "static inline" 函数，或者宏，在代码里用这些东
|
||||
西。让编译器把那些"空操作"优化掉。
|
||||
|
||||
一个简单的例子，不好的代码：
|
||||
|
||||
dev = alloc_etherdev (sizeof(struct funky_private));
|
||||
if (!dev)
|
||||
return -ENODEV;
|
||||
#ifdef CONFIG_NET_FUNKINESS
|
||||
init_funky_net(dev);
|
||||
#endif
|
||||
|
||||
清理后的例子:
|
||||
|
||||
(头文件里)
|
||||
#ifndef CONFIG_NET_FUNKINESS
|
||||
static inline void init_funky_net (struct net_device *d) {}
|
||||
#endif
|
||||
|
||||
(代码文件里)
|
||||
dev = alloc_etherdev (sizeof(struct funky_private));
|
||||
if (!dev)
|
||||
return -ENODEV;
|
||||
init_funky_net(dev);
|
||||
|
||||
3) 'static inline' 比宏好
|
||||
|
||||
Static inline 函数相比宏来说，是好得多的选择。Static inline 函数提供了
|
||||
类型安全，没有长度限制，没有格式限制，在 gcc 下开销和宏一样小。
|
||||
|
||||
宏只在 static inline 函数不是最优的时候[在 fast paths 里有很少的独立的
|
||||
案例]，或者不可能用 static inline 函数的时候[例如字符串分配]。
|
||||
应该用 'static inline' 而不是 'static __inline__', 'extern inline' 和
|
||||
'extern __inline__' 。
|
||||
|
||||
4) 不要过度设计
|
||||
|
||||
不要试图预计模糊的未来事情，这些事情也许有用也许没有用："让事情尽可能的
|
||||
简单，而不是更简单"。
|
||||
|
||||
----------------
|
||||
第三节 参考文献
|
||||
----------------
|
||||
|
||||
Andrew Morton, "The perfect patch" (tpp).
|
||||
<http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt>
|
||||
|
||||
Jeff Garzik, "Linux kernel patch submission format".
|
||||
<http://linux.yyz.us/patch-format.html>
|
||||
|
||||
Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
|
||||
<http://www.kroah.com/log/2005/03/31/>
|
||||
<http://www.kroah.com/log/2005/07/08/>
|
||||
<http://www.kroah.com/log/2005/10/19/>
|
||||
<http://www.kroah.com/log/2006/01/11/>
|
||||
|
||||
NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
|
||||
<http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
|
||||
|
||||
Kernel Documentation/CodingStyle:
|
||||
<http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle>
|
||||
|
||||
Linus Torvalds's mail on the canonical patch format:
|
||||
<http://lkml.org/lkml/2005/4/7/183>
|
||||
--
|
||||
@@ -0,0 +1,212 @@
|
||||
Chinese translated version of Documentation/oops-tracing.txt
|
||||
|
||||
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: Dave Young <hidave.darkstar@gmail.com>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/oops-tracing.txt 的中文翻译
|
||||
|
||||
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
|
||||
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
|
||||
译存在问题，请联系中文版维护者。
|
||||
|
||||
中文版维护者： 杨瑞 Dave Young <hidave.darkstar@gmail.com>
|
||||
中文版翻译者： 杨瑞 Dave Young <hidave.darkstar@gmail.com>
|
||||
中文版校译者： 李阳 Li Yang <leo@zh-kernel.org>
|
||||
王聪 Wang Cong <xiyou.wangcong@gmail.com>
|
||||
|
||||
以下为正文
|
||||
---------------------------------------------------------------------
|
||||
|
||||
注意： ksymoops 在2.6中是没有用的。 请以原有格式使用Oops(来自dmesg，等等)。
|
||||
忽略任何这样那样关于“解码Oops”或者“通过ksymoops运行”的文档。 如果你贴出运行过
|
||||
ksymoops的来自2.6的Oops，人们只会让你重贴一次。
|
||||
|
||||
快速总结
|
||||
-------------
|
||||
|
||||
发现Oops并发送给看似相关的内核领域的维护者。别太担心对不上号。如果你不确定就发给
|
||||
和你所做的事情相关的代码的负责人。 如果可重现试着描述怎样重构。 那甚至比oops更有
|
||||
价值。
|
||||
|
||||
如果你对于发送给谁一无所知， 发给linux-kernel@vger.kernel.org。感谢你帮助Linux
|
||||
尽可能地稳定。
|
||||
|
||||
Oops在哪里?
|
||||
----------------------
|
||||
|
||||
通常Oops文本由klogd从内核缓冲区里读取并传给syslogd，由syslogd写到syslog文件中，
|
||||
典型地是/var/log/messages(依赖于/etc/syslog.conf)。有时klogd崩溃了,这种情况下你
|
||||
能够运行dmesg > file来从内核缓冲区中读取数据并保存下来。 否则你可以
|
||||
cat /proc/kmsg > file， 然而你必须介入中止传输， kmsg是一个“永不结束的文件”。如
|
||||
果机器崩溃坏到你不能输入命令或者磁盘不可用那么你有三种选择:-
|
||||
|
||||
（1） 手抄屏幕上的文本待机器重启后再输入计算机。 麻烦但如果没有针对崩溃的准备，
|
||||
这是仅有的选择。 另外，你可以用数码相机把屏幕拍下来-不太好，但比没有强。 如果信
|
||||
息滚动到了终端的上面，你会发现以高分辩率启动（比如，vga=791）会让你读到更多的文
|
||||
本。（注意：这需要vesafb，所以对‘早期’的oops没有帮助）
|
||||
|
||||
（2）用串口终端启动（请参看Documentation/serial-console.txt），运行一个null
|
||||
modem到另一台机器并用你喜欢的通讯工具获取输出。Minicom工作地很好。
|
||||
|
||||
（3）使用Kdump（请参看Documentation/kdump/kdump.txt），
|
||||
使用在Documentation/kdump/gdbmacros.txt中定义的dmesg gdb宏，从旧的内存中提取内核
|
||||
环形缓冲区。
|
||||
|
||||
完整信息
|
||||
----------------
|
||||
|
||||
注意：以下来自于Linus的邮件适用于2.4内核。 我因为历史原因保留了它，并且因为其中
|
||||
一些信息仍然适用。 特别注意的是，请忽略任何ksymoops的引用。
|
||||
|
||||
From: Linus Torvalds <torvalds@osdl.org>
|
||||
|
||||
怎样跟踪Oops.. [原发到linux-kernel的一封邮件]
|
||||
|
||||
主要的窍门是有五年和这些烦人的oops消息打交道的经验;-)
|
||||
|
||||
实际上，你有办法使它更简单。我有两个不同的方法：
|
||||
|
||||
gdb /usr/src/linux/vmlinux
|
||||
gdb> disassemble <offending_function>
|
||||
|
||||
那是发现问题的简单办法，至少如果bug报告做的好的情况下（象这个一样-运行ksymoops
|
||||
得到oops发生的函数及函数内的偏移）。
|
||||
|
||||
哦，如果报告发生的内核以相同的编译器和相似的配置编译它会有帮助的。
|
||||
|
||||
另一件要做的事是反汇编bug报告的“Code”部分：ksymoops也会用正确的工具来做这件事，
|
||||
但如果没有那些工具你可以写一个傻程序：
|
||||
|
||||
char str[] = "\xXX\xXX\xXX...";
|
||||
main(){}
|
||||
|
||||
并用gcc -g编译它然后执行“disassemble str”（XX部分是由Oops报告的值-你可以仅剪切
|
||||
粘贴并用“\x”替换空格-我就是这么做的，因为我懒得写程序自动做这一切）。
|
||||
|
||||
另外，你可以用scripts/decodecode这个shell脚本。它的使用方法是：
|
||||
decodecode < oops.txt
|
||||
|
||||
“Code”之后的十六进制字节可能（在某些架构上）有一些当前指令之前的指令字节以及
|
||||
当前和之后的指令字节
|
||||
|
||||
Code: f9 0f 8d f9 00 00 00 8d 42 0c e8 dd 26 11 c7 a1 60 ea 2b f9 8b 50 08 a1
|
||||
64 ea 2b f9 8d 34 82 8b 1e 85 db 74 6d 8b 15 60 ea 2b f9 <8b> 43 04 39 42 54
|
||||
7e 04 40 89 42 54 8b 43 04 3b 05 00 f6 52 c0
|
||||
|
||||
最后，如果你想知道代码来自哪里，你可以：
|
||||
|
||||
cd /usr/src/linux
|
||||
make fs/buffer.s # 或任何产生BUG的文件
|
||||
|
||||
然后你会比gdb反汇编更清楚的知道发生了什么。
|
||||
|
||||
现在，问题是把你所拥有的所有数据结合起来：C源码（关于它应该怎样的一般知识），
|
||||
汇编代码及其反汇编得到的代码（另外还有从“oops”消息得到的寄存器状态-对了解毁坏的
|
||||
指针有用，而且当你有了汇编代码你也能拿其它的寄存器和任何它们对应的C表达式做匹配
|
||||
）。
|
||||
|
||||
实际上，你仅需看看哪里不匹配（这个例子是“Code”反汇编和编译器生成的代码不匹配）。
|
||||
然后你须要找出为什么不匹配。通常很简单-你看到代码使用了空指针然后你看代码想知道
|
||||
空指针是怎么出现的，还有检查它是否合法..
|
||||
|
||||
现在，如果明白这是一项耗时的工作而且需要一丁点儿的专心，没错。这就是我为什么大多
|
||||
只是忽略那些没有符号表信息的崩溃报告的原因：简单的说太难查找了（我有一些
|
||||
程序用于在内核代码段中搜索特定的模式，而且有时我也已经能找出那些崩溃的地方，但是
|
||||
仅仅是找出正确的序列也确实需要相当扎实的内核知识）
|
||||
|
||||
_有时_会发生这种情况，我仅看到崩溃中的反汇编代码序列， 然后我马上就明白问题出在
|
||||
哪里。这时我才意识到自己干这个工作已经太长时间了;-)
|
||||
|
||||
Linus
|
||||
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
关于Oops跟踪的注解：
|
||||
|
||||
为了帮助Linus和其它内核开发者，klogd纳入了大量的支持来处理保护错误。为了拥有对
|
||||
地址解析的完整支持至少应该使用1.3-pl3的sysklogd包。
|
||||
|
||||
当保护错误发生时，klogd守护进程自动把内核日志信息中的重要地址翻译成它们相应的符
|
||||
号。
|
||||
|
||||
klogd执行两种类型的地址解析。首先是静态翻译其次是动态翻译。静态翻译和ksymoops
|
||||
一样使用System.map文件。为了做静态翻译klogd守护进程必须在初始化时能找到system
|
||||
map文件。关于klogd怎样搜索map文件请参看klogd手册页。
|
||||
|
||||
动态地址翻译在使用内核可装载模块时很重要。 因为内核模块的内存是从内核动态内存池
|
||||
里分配的，所以不管是模块开始位置还是模块中函数和符号的位置都不是固定的。
|
||||
|
||||
内核支持允许程序决定装载哪些模块和它们在内存中位置的系统调用。使用这些系统调用
|
||||
klogd守护进程生成一张符号表用于调试发生在可装载模块中的保护错误。
|
||||
|
||||
至少klogd会提供产生保护错误的模块名。还可有额外的符号信息供可装载模块开发者选择
|
||||
以从模块中输出符号信息。
|
||||
|
||||
因为内核模块环境可能是动态的，所以必须有一种机制当模块环境发生改变时来通知klogd
|
||||
守护进程。 有一些可用的命令行选项允许klogd向当前执行中的守护进程发送信号，告知符
|
||||
号信息应该被刷新了。 更多信息请参看klogd手册页。
|
||||
|
||||
sysklogd发布时包含一个补丁修改了modules-2.0.0包，无论何时一个模块装载或者卸载都
|
||||
会自动向klogd发送信号。打上这个补丁提供了必要的对调试发生于内核可装载模块的保护
|
||||
错误的无缝支持。
|
||||
|
||||
以下是被klogd处理过的发生在可装载模块中的一个保护错误例子：
|
||||
---------------------------------------------------------------------------
|
||||
Aug 29 09:51:01 blizard kernel: Unable to handle kernel paging request at virtual address f15e97cc
|
||||
Aug 29 09:51:01 blizard kernel: current->tss.cr3 = 0062d000, %cr3 = 0062d000
|
||||
Aug 29 09:51:01 blizard kernel: *pde = 00000000
|
||||
Aug 29 09:51:01 blizard kernel: Oops: 0002
|
||||
Aug 29 09:51:01 blizard kernel: CPU: 0
|
||||
Aug 29 09:51:01 blizard kernel: EIP: 0010:[oops:_oops+16/3868]
|
||||
Aug 29 09:51:01 blizard kernel: EFLAGS: 00010212
|
||||
Aug 29 09:51:01 blizard kernel: eax: 315e97cc ebx: 003a6f80 ecx: 001be77b edx: 00237c0c
|
||||
Aug 29 09:51:01 blizard kernel: esi: 00000000 edi: bffffdb3 ebp: 00589f90 esp: 00589f8c
|
||||
Aug 29 09:51:01 blizard kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
|
||||
Aug 29 09:51:01 blizard kernel: Process oops_test (pid: 3374, process nr: 21, stackpage=00589000)
|
||||
Aug 29 09:51:01 blizard kernel: Stack: 315e97cc 00589f98 0100b0b4 bffffed4 0012e38e 00240c64 003a6f80 00000001
|
||||
Aug 29 09:51:01 blizard kernel: 00000000 00237810 bfffff00 0010a7fa 00000003 00000001 00000000 bfffff00
|
||||
Aug 29 09:51:01 blizard kernel: bffffdb3 bffffed4 ffffffda 0000002b 0007002b 0000002b 0000002b 00000036
|
||||
Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128]
|
||||
Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
Dr. G.W. Wettstein Oncology Research Div. Computing Facility
|
||||
Roger Maris Cancer Center INTERNET: greg@wind.rmcc.com
|
||||
820 4th St. N.
|
||||
Fargo, ND 58122
|
||||
Phone: 701-234-7556
|
||||
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
受污染的内核
|
||||
|
||||
一些oops报告在程序记数器之后包含字符串'Tainted: '。这表明内核已经被一些东西给污
|
||||
染了。 该字符串之后紧跟着一系列的位置敏感的字符，每个代表一个特定的污染值。
|
||||
|
||||
1：'G'如果所有装载的模块都有GPL或相容的许可证，'P'如果装载了任何的专有模块。
|
||||
没有模块MODULE_LICENSE或者带有insmod认为是与GPL不相容的的MODULE_LICENSE的模块被
|
||||
认定是专有的。
|
||||
|
||||
2：'F'如果有任何通过“insmod -f”被强制装载的模块，' '如果所有模块都被正常装载。
|
||||
|
||||
3：'S'如果oops发生在SMP内核中，运行于没有证明安全运行多处理器的硬件。 当前这种
|
||||
情况仅限于几种不支持SMP的速龙处理器。
|
||||
|
||||
4：'R'如果模块通过“insmod -f”被强制装载，' '如果所有模块都被正常装载。
|
||||
|
||||
5：'M'如果任何处理器报告了机器检查异常，' '如果没有发生机器检查异常。
|
||||
|
||||
6：'B'如果页释放函数发现了一个错误的页引用或者一些非预期的页标志。
|
||||
|
||||
7：'U'如果用户或者用户应用程序特别请求设置污染标志，否则' '。
|
||||
|
||||
8：'D'如果内核刚刚死掉，比如有OOPS或者BUG。
|
||||
|
||||
使用'Tainted: '字符串的主要原因是要告诉内核调试者，这是否是一个干净的内核亦或发
|
||||
生了任何的不正常的事。污染是永久的：即使出错的模块已经被卸载了，污染值仍然存在，
|
||||
以表明内核不再值得信任。
|
||||
@@ -0,0 +1,100 @@
|
||||
Chinese translated version of Documentation/sparse.txt
|
||||
|
||||
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: Li Yang <leo@zh-kernel.org>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/sparse.txt 的中文翻译
|
||||
|
||||
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
|
||||
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
|
||||
译存在问题，请联系中文版维护者。
|
||||
|
||||
中文版维护者： 李阳 Li Yang <leo@zh-kernel.org>
|
||||
中文版翻译者： 李阳 Li Yang <leo@zh-kernel.org>
|
||||
|
||||
|
||||
以下为正文
|
||||
---------------------------------------------------------------------
|
||||
|
||||
Copyright 2004 Linus Torvalds
|
||||
Copyright 2004 Pavel Machek <pavel@suse.cz>
|
||||
Copyright 2006 Bob Copeland <me@bobcopeland.com>
|
||||
|
||||
使用 sparse 工具做类型检查
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
"__bitwise" 是一种类型属性，所以你应该这样使用它：
|
||||
|
||||
typedef int __bitwise pm_request_t;
|
||||
|
||||
enum pm_request {
|
||||
PM_SUSPEND = (__force pm_request_t) 1,
|
||||
PM_RESUME = (__force pm_request_t) 2
|
||||
};
|
||||
|
||||
这样会使 PM_SUSPEND 和 PM_RESUME 成为位方式(bitwise)整数（使用"__force"
|
||||
是因为 sparse 会抱怨改变位方式的类型转换，但是这里我们确实需要强制进行转
|
||||
换）。而且因为所有枚举值都使用了相同的类型，这里的"enum pm_request"也将
|
||||
会使用那个类型做为底层实现。
|
||||
|
||||
而且使用 gcc 编译的时候，所有的 __bitwise/__force 都会消失，最后在 gcc
|
||||
看来它们只不过是普通的整数。
|
||||
|
||||
坦白来说，你并不需要使用枚举类型。上面那些实际都可以浓缩成一个特殊的"int
|
||||
__bitwise"类型。
|
||||
|
||||
所以更简单的办法只要这样做：
|
||||
|
||||
typedef int __bitwise pm_request_t;
|
||||
|
||||
#define PM_SUSPEND ((__force pm_request_t) 1)
|
||||
#define PM_RESUME ((__force pm_request_t) 2)
|
||||
|
||||
现在你就有了严格的类型检查所需要的所有基础架构。
|
||||
|
||||
一个小提醒：常数整数"0"是特殊的。你可以直接把常数零当作位方式整数使用而
|
||||
不用担心 sparse 会抱怨。这是因为"bitwise"（恰如其名）是用来确保不同位方
|
||||
式类型不会被弄混（小尾模式，大尾模式，cpu尾模式，或者其他），对他们来说
|
||||
常数"0"确实是特殊的。
|
||||
|
||||
获取 sparse 工具
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
你可以从 Sparse 的主页获取最新的发布版本：
|
||||
|
||||
http://www.kernel.org/pub/linux/kernel/people/josh/sparse/
|
||||
|
||||
或者，你也可以使用 git 克隆最新的 sparse 开发版本：
|
||||
|
||||
git://git.kernel.org/pub/scm/linux/kernel/git/josh/sparse.git
|
||||
|
||||
DaveJ 把每小时自动生成的 git 源码树 tar 包放在以下地址：
|
||||
|
||||
http://www.codemonkey.org.uk/projects/git-snapshots/sparse/
|
||||
|
||||
一旦你下载了源码，只要以普通用户身份运行：
|
||||
|
||||
make
|
||||
make install
|
||||
|
||||
它将会被自动安装到你的 ~/bin 目录下。
|
||||
|
||||
使用 sparse 工具
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
用"make C=1"命令来编译内核，会对所有重新编译的 C 文件使用 sparse 工具。
|
||||
或者使用"make C=2"命令，无论文件是否被重新编译都会对其使用 sparse 工具。
|
||||
如果你已经编译了内核，用后一种方式可以很快地检查整个源码树。
|
||||
|
||||
make 的可选变量 CHECKFLAGS 可以用来向 sparse 工具传递参数。编译系统会自
|
||||
动向 sparse 工具传递 -Wbitwise 参数。你可以定义 __CHECK_ENDIAN__ 来进行
|
||||
大小尾检查。
|
||||
|
||||
make C=2 CHECKFLAGS="-D__CHECK_ENDIAN__"
|
||||
|
||||
这些检查默认都是被关闭的，因为他们通常会产生大量的警告。
|
||||
@@ -0,0 +1,66 @@
|
||||
Chinese translated version of Documentation/stable_kernel_rules.txt
|
||||
|
||||
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: TripleX Chung <triplex@zh-kernel.org>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/stable_kernel_rules.txt 的中文翻译
|
||||
|
||||
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
|
||||
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
|
||||
译存在问题，请联系中文版维护者。
|
||||
|
||||
|
||||
中文版维护者： 钟宇 TripleX Chung <triplex@zh-kernel.org>
|
||||
中文版翻译者： 钟宇 TripleX Chung <triplex@zh-kernel.org>
|
||||
中文版校译者： 李阳 Li Yang <leo@zh-kernel.org>
|
||||
Kangkai Yin <e12051@motorola.com>
|
||||
|
||||
以下为正文
|
||||
---------------------------------------------------------------------
|
||||
|
||||
关于Linux 2.6稳定版发布，所有你想知道的事情。
|
||||
|
||||
关于哪些类型的补丁可以被接收进入稳定版代码树，哪些不可以的规则：
|
||||
|
||||
- 必须是显而易见的正确，并且经过测试的。
|
||||
- 连同上下文，不能大于100行。
|
||||
- 必须只修正一件事情。
|
||||
- 必须修正了一个给大家带来麻烦的真正的bug（不是“这也许是一个问题...”
|
||||
那样的东西）。
|
||||
- 必须修正带来如下后果的问题：编译错误（对被标记为CONFIG_BROKEN的例外），
|
||||
内核崩溃，挂起，数据损坏，真正的安全问题，或者一些类似“哦，这不
|
||||
好”的问题。简短的说，就是一些致命的问题。
|
||||
- 没有“理论上的竞争条件”，除非能给出竞争条件如何被利用的解释。
|
||||
- 不能存在任何的“琐碎的”修正（拼写修正，去掉多余空格之类的）。
|
||||
- 必须被相关子系统的维护者接受。
|
||||
- 必须遵循Documentation/SubmittingPatches里的规则。
|
||||
|
||||
向稳定版代码树提交补丁的过程：
|
||||
|
||||
- 在确认了补丁符合以上的规则后，将补丁发送到stable@kernel.org。
|
||||
- 如果补丁被接受到队列里，发送者会收到一个ACK回复，如果没有被接受，收
|
||||
到的是NAK回复。回复需要几天的时间，这取决于开发者的时间安排。
|
||||
- 被接受的补丁会被加到稳定版本队列里，等待其他开发者的审查。
|
||||
- 安全方面的补丁不要发到这个列表，应该发送到security@kernel.org。
|
||||
|
||||
审查周期：
|
||||
|
||||
- 当稳定版的维护者决定开始一个审查周期，补丁将被发送到审查委员会，以
|
||||
及被补丁影响的领域的维护者（除非提交者就是该领域的维护者）并且抄送
|
||||
到linux-kernel邮件列表。
|
||||
- 审查委员会有48小时的时间，用来决定给该补丁回复ACK还是NAK。
|
||||
- 如果委员会中有成员拒绝这个补丁，或者linux-kernel列表上有人反对这个
|
||||
补丁，并提出维护者和审查委员会之前没有意识到的问题，补丁会从队列中
|
||||
丢弃。
|
||||
- 在审查周期结束的时候，那些得到ACK回应的补丁将会被加入到最新的稳定版
|
||||
发布中，一个新的稳定版发布就此产生。
|
||||
- 安全性补丁将从内核安全小组那里直接接收到稳定版代码树中，而不是通过
|
||||
通常的审查周期。请联系内核安全小组以获得关于这个过程的更多细节。
|
||||
|
||||
审查委员会：
|
||||
- 由一些自愿承担这项任务的内核开发者，和几个非志愿的组成。
|
||||
@@ -0,0 +1,113 @@
|
||||
Chinese translated version of Documentation/volatile-considered-harmful.txt
|
||||
|
||||
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: Jonathan Corbet <corbet@lwn.net>
|
||||
Chinese maintainer: Bryan Wu <bryan.wu@analog.com>
|
||||
---------------------------------------------------------------------
|
||||
Documentation/volatile-considered-harmful.txt 的中文翻译
|
||||
|
||||
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
|
||||
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
|
||||
译存在问题，请联系中文版维护者。
|
||||
|
||||
英文版维护者： Jonathan Corbet <corbet@lwn.net>
|
||||
中文版维护者： 伍鹏 Bryan Wu <bryan.wu@analog.com>
|
||||
中文版翻译者： 伍鹏 Bryan Wu <bryan.wu@analog.com>
|
||||
中文版校译者： 张汉辉 Eugene Teo <eugeneteo@kernel.sg>
|
||||
杨瑞 Dave Young <hidave.darkstar@gmail.com>
|
||||
以下为正文
|
||||
---------------------------------------------------------------------
|
||||
|
||||
为什么不应该使用“volatile”类型
|
||||
------------------------------
|
||||
|
||||
C程序员通常认为volatile表示某个变量可以在当前执行的线程之外被改变；因此，在内核
|
||||
中用到共享数据结构时，常常会有C程序员喜欢使用volatile这类变量。换句话说，他们经
|
||||
常会把volatile类型看成某种简易的原子变量，当然它们不是。在内核中使用volatile几
|
||||
乎总是错误的；本文档将解释为什么这样。
|
||||
|
||||
理解volatile的关键是知道它的目的是用来消除优化，实际上很少有人真正需要这样的应
|
||||
用。在内核中，程序员必须防止意外的并发访问破坏共享的数据结构，这其实是一个完全
|
||||
不同的任务。用来防止意外并发访问的保护措施，可以更加高效的避免大多数优化相关的
|
||||
问题。
|
||||
|
||||
像volatile一样，内核提供了很多原语来保证并发访问时的数据安全（自旋锁, 互斥量,内
|
||||
存屏障等等），同样可以防止意外的优化。如果可以正确使用这些内核原语，那么就没有
|
||||
必要再使用volatile。如果仍然必须使用volatile，那么几乎可以肯定在代码的某处有一
|
||||
个bug。在正确设计的内核代码中，volatile能带来的仅仅是使事情变慢。
|
||||
|
||||
思考一下这段典型的内核代码：
|
||||
|
||||
spin_lock(&the_lock);
|
||||
do_something_on(&shared_data);
|
||||
do_something_else_with(&shared_data);
|
||||
spin_unlock(&the_lock);
|
||||
|
||||
如果所有的代码都遵循加锁规则，当持有the_lock的时候，不可能意外的改变shared_data的
|
||||
值。任何可能访问该数据的其他代码都会在这个锁上等待。自旋锁原语跟内存屏障一样—— 它
|
||||
们显式的用来书写成这样 —— 意味着数据访问不会跨越它们而被优化。所以本来编译器认为
|
||||
它知道在shared_data里面将有什么，但是因为spin_lock()调用跟内存屏障一样，会强制编
|
||||
译器忘记它所知道的一切。那么在访问这些数据时不会有优化的问题。
|
||||
|
||||
如果shared_data被声名为volatile，锁操作将仍然是必须的。就算我们知道没有其他人正在
|
||||
使用它，编译器也将被阻止优化对临界区内shared_data的访问。在锁有效的同时，
|
||||
shared_data不是volatile的。在处理共享数据的时候，适当的锁操作可以不再需要
|
||||
volatile —— 并且是有潜在危害的。
|
||||
|
||||
volatile的存储类型最初是为那些内存映射的I/O寄存器而定义。在内核里，寄存器访问也应
|
||||
该被锁保护，但是人们也不希望编译器“优化”临界区内的寄存器访问。内核里I/O的内存访问
|
||||
是通过访问函数完成的；不赞成通过指针对I/O内存的直接访问，并且不是在所有体系架构上
|
||||
都能工作。那些访问函数正是为了防止意外优化而写的，因此，再说一次，volatile类型不
|
||||
是必需的。
|
||||
|
||||
另一种引起用户可能使用volatile的情况是当处理器正忙着等待一个变量的值。正确执行一
|
||||
个忙等待的方法是：
|
||||
|
||||
while (my_variable != what_i_want)
|
||||
cpu_relax();
|
||||
|
||||
cpu_relax()调用会降低CPU的能量消耗或者让位于超线程双处理器；它也作为内存屏障一样出
|
||||
现，所以，再一次，volatile不是必需的。当然，忙等待一开始就是一种反常规的做法。
|
||||
|
||||
在内核中，一些稀少的情况下volatile仍然是有意义的：
|
||||
|
||||
- 在一些体系架构的系统上，允许直接的I/0内存访问，那么前面提到的访问函数可以使用
|
||||
volatile。基本上，每一个访问函数调用它自己都是一个小的临界区域并且保证了按照
|
||||
程序员期望的那样发生访问操作。
|
||||
|
||||
- 某些会改变内存的内联汇编代码虽然没有什么其他明显的附作用，但是有被GCC删除的可
|
||||
能性。在汇编声明中加上volatile关键字可以防止这种删除操作。
|
||||
|
||||
- Jiffies变量是一种特殊情况，虽然每次引用它的时候都可以有不同的值，但读jiffies
|
||||
变量时不需要任何特殊的加锁保护。所以jiffies变量可以使用volatile，但是不赞成
|
||||
其他跟jiffies相同类型变量使用volatile。Jiffies被认为是一种“愚蠢的遗留物"
|
||||
（Linus的话）因为解决这个问题比保持现状要麻烦的多。
|
||||
|
||||
- 由于某些I/0设备可能会修改连续一致的内存,所以有时,指向连续一致内存的数据结构
|
||||
的指针需要正确的使用volatile。网络适配器使用的环状缓存区正是这类情形的一个例
|
||||
子，其中适配器用改变指针来表示哪些描述符已经处理过了。
|
||||
|
||||
对于大多代码，上述几种可以使用volatile的情况都不适用。所以，使用volatile是一种
|
||||
bug并且需要对这样的代码额外仔细检查。那些试图使用volatile的开发人员需要退一步想想
|
||||
他们真正想实现的是什么。
|
||||
|
||||
非常欢迎删除volatile变量的补丁 － 只要证明这些补丁完整的考虑了并发问题。
|
||||
|
||||
注释
|
||||
----
|
||||
|
||||
[1] http://lwn.net/Articles/233481/
|
||||
[2] http://lwn.net/Articles/233482/
|
||||
|
||||
致谢
|
||||
----
|
||||
|
||||
最初由Randy Dunlap推动并作初步研究
|
||||
由Jonathan Corbet撰写
|
||||
参考Satyam Sharma，Johannes Stezenbach，Jesper Juhl，Heikki Orsila，
|
||||
H. Peter Anvin，Philipp Hahn和Stefan Richter的意见改善了本档。
|
||||
@@ -195,7 +195,7 @@ static int leds_shutdown(struct sys_device *dev)
|
||||
}
|
||||
|
||||
static struct sysdev_class leds_sysclass = {
|
||||
set_kset_name("leds"),
|
||||
.name = "leds",
|
||||
.shutdown = leds_shutdown,
|
||||
.suspend = leds_suspend,
|
||||
.resume = leds_resume,
|
||||
@@ -369,7 +369,7 @@ static int timer_resume(struct sys_device *dev)
|
||||
#endif
|
||||
|
||||
static struct sysdev_class timer_sysclass = {
|
||||
set_kset_name("timer"),
|
||||
.name = "timer",
|
||||
.suspend = timer_suspend,
|
||||
.resume = timer_resume,
|
||||
};
|
||||
|
||||
@@ -214,7 +214,7 @@ static int irq_resume(struct sys_device *dev)
|
||||
#endif
|
||||
|
||||
static struct sysdev_class irq_class = {
|
||||
set_kset_name("irq"),
|
||||
.name = "irq",
|
||||
.suspend = irq_suspend,
|
||||
.resume = irq_resume,
|
||||
};
|
||||
|
||||
@@ -69,14 +69,14 @@ static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
|
||||
|
||||
static unsigned short enable_dyn_sleep = 1;
|
||||
|
||||
static ssize_t omap_pm_sleep_while_idle_show(struct kset *kset, char *buf)
|
||||
static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
|
||||
char *buf)
|
||||
{
|
||||
return sprintf(buf, "%hu\n", enable_dyn_sleep);
|
||||
}
|
||||
|
||||
static ssize_t omap_pm_sleep_while_idle_store(struct kset *kset,
|
||||
const char * buf,
|
||||
size_t n)
|
||||
static ssize_t idle_store(struct kobject *kobj, struct kobj_attribute *attr,
|
||||
const char * buf, size_t n)
|
||||
{
|
||||
unsigned short value;
|
||||
if (sscanf(buf, "%hu", &value) != 1 ||
|
||||
@@ -88,16 +88,9 @@ static ssize_t omap_pm_sleep_while_idle_store(struct kset *kset,
|
||||
return n;
|
||||
}
|
||||
|
||||
static struct subsys_attribute sleep_while_idle_attr = {
|
||||
.attr = {
|
||||
.name = __stringify(sleep_while_idle),
|
||||
.mode = 0644,
|
||||
},
|
||||
.show = omap_pm_sleep_while_idle_show,
|
||||
.store = omap_pm_sleep_while_idle_store,
|
||||
};
|
||||
static struct kobj_attribute sleep_while_idle_attr =
|
||||
__ATTR(sleep_while_idle, 0644, idle_show, idle_store);
|
||||
|
||||
extern struct kset power_subsys;
|
||||
static void (*omap_sram_idle)(void) = NULL;
|
||||
static void (*omap_sram_suspend)(unsigned long r0, unsigned long r1) = NULL;
|
||||
|
||||
@@ -726,9 +719,9 @@ static int __init omap_pm_init(void)
|
||||
omap_pm_init_proc();
|
||||
#endif
|
||||
|
||||
error = subsys_create_file(&power_subsys, &sleep_while_idle_attr);
|
||||
error = sysfs_create_file(power_kobj, &sleep_while_idle_attr);
|
||||
if (error)
|
||||
printk(KERN_ERR "subsys_create_file failed: %d\n", error);
|
||||
printk(KERN_ERR "sysfs_create_file failed: %d\n", error);
|
||||
|
||||
if (cpu_is_omap16xx()) {
|
||||
/* configure LOW_PWR pin */
|
||||
|
||||
@@ -566,7 +566,7 @@ static int cmx270_resume(struct sys_device *dev)
|
||||
}
|
||||
|
||||
static struct sysdev_class cmx270_pm_sysclass = {
|
||||
set_kset_name("pm"),
|
||||
.name = "pm",
|
||||
.resume = cmx270_resume,
|
||||
.suspend = cmx270_suspend,
|
||||
};
|
||||
|
||||
@@ -122,7 +122,7 @@ static int lpd270_irq_resume(struct sys_device *dev)
|
||||
}
|
||||
|
||||
static struct sysdev_class lpd270_irq_sysclass = {
|
||||
set_kset_name("cpld_irq"),
|
||||
.name = "cpld_irq",
|
||||
.resume = lpd270_irq_resume,
|
||||
};
|
||||
|
||||
|
||||
@@ -126,7 +126,7 @@ static int lubbock_irq_resume(struct sys_device *dev)
|
||||
}
|
||||
|
||||
static struct sysdev_class lubbock_irq_sysclass = {
|
||||
set_kset_name("cpld_irq"),
|
||||
.name = "cpld_irq",
|
||||
.resume = lubbock_irq_resume,
|
||||
};
|
||||
|
||||
|
||||
@@ -120,7 +120,7 @@ static int mainstone_irq_resume(struct sys_device *dev)
|
||||
}
|
||||
|
||||
static struct sysdev_class mainstone_irq_sysclass = {
|
||||
set_kset_name("cpld_irq"),
|
||||
.name = "cpld_irq",
|
||||
.resume = mainstone_irq_resume,
|
||||
};
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user