diff options
-rw-r--r-- | Documentation/driver-model/device.txt | 2 | ||||
-rw-r--r-- | Documentation/driver-model/overview.txt | 52 | ||||
-rw-r--r-- | Documentation/filesystems/debugfs.txt | 4 | ||||
-rw-r--r-- | Documentation/ja_JP/SubmittingPatches | 258 | ||||
-rw-r--r-- | Documentation/zh_CN/email-clients.txt | 210 | ||||
-rw-r--r-- | drivers/base/Kconfig | 64 | ||||
-rw-r--r-- | drivers/firmware/google/gsmi.c | 19 | ||||
-rw-r--r-- | drivers/misc/pti.c | 6 | ||||
-rw-r--r-- | drivers/uio/uio_pdrv_genirq.c | 43 |
9 files changed, 448 insertions, 210 deletions
diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt index b2ff42685bcb..bdefe728a737 100644 --- a/Documentation/driver-model/device.txt +++ b/Documentation/driver-model/device.txt | |||
@@ -104,4 +104,4 @@ Then in the module init function is would do: | |||
104 | 104 | ||
105 | And assuming 'dev' is the struct device passed into the probe hook, the driver | 105 | And assuming 'dev' is the struct device passed into the probe hook, the driver |
106 | probe function would do something like: | 106 | probe function would do something like: |
107 | create_device(&mydriver_class, dev, chrdev, &private_data, "my_name"); | 107 | device_create(&mydriver_class, dev, chrdev, &private_data, "my_name"); |
diff --git a/Documentation/driver-model/overview.txt b/Documentation/driver-model/overview.txt index 07236ed968da..6a8f9a8075d8 100644 --- a/Documentation/driver-model/overview.txt +++ b/Documentation/driver-model/overview.txt | |||
@@ -30,7 +30,7 @@ management, and hot plug. In particular, the model dictated by Intel and | |||
30 | Microsoft (namely ACPI) ensures that almost every device on almost any bus | 30 | Microsoft (namely ACPI) ensures that almost every device on almost any bus |
31 | on an x86-compatible system can work within this paradigm. Of course, | 31 | on an x86-compatible system can work within this paradigm. Of course, |
32 | not every bus is able to support all such operations, although most | 32 | not every bus is able to support all such operations, although most |
33 | buses support a most of those operations. | 33 | buses support most of those operations. |
34 | 34 | ||
35 | 35 | ||
36 | Downstream Access | 36 | Downstream Access |
@@ -46,25 +46,29 @@ struct pci_dev now looks like this: | |||
46 | struct pci_dev { | 46 | struct pci_dev { |
47 | ... | 47 | ... |
48 | 48 | ||
49 | struct device dev; | 49 | struct device dev; /* Generic device interface */ |
50 | ... | ||
50 | }; | 51 | }; |
51 | 52 | ||
52 | Note first that it is statically allocated. This means only one allocation on | 53 | Note first that the struct device dev within the struct pci_dev is |
53 | device discovery. Note also that it is at the _end_ of struct pci_dev. This is | 54 | statically allocated. This means only one allocation on device discovery. |
54 | to make people think about what they're doing when switching between the bus | 55 | |
55 | driver and the global driver; and to prevent against mindless casts between | 56 | Note also that that struct device dev is not necessarily defined at the |
56 | the two. | 57 | front of the pci_dev structure. This is to make people think about what |
58 | they're doing when switching between the bus driver and the global driver, | ||
59 | and to discourage meaningless and incorrect casts between the two. | ||
57 | 60 | ||
58 | The PCI bus layer freely accesses the fields of struct device. It knows about | 61 | The PCI bus layer freely accesses the fields of struct device. It knows about |
59 | the structure of struct pci_dev, and it should know the structure of struct | 62 | the structure of struct pci_dev, and it should know the structure of struct |
60 | device. Individual PCI device drivers that have been converted to the current | 63 | device. Individual PCI device drivers that have been converted to the current |
61 | driver model generally do not and should not touch the fields of struct device, | 64 | driver model generally do not and should not touch the fields of struct device, |
62 | unless there is a strong compelling reason to do so. | 65 | unless there is a compelling reason to do so. |
63 | 66 | ||
64 | This abstraction is prevention of unnecessary pain during transitional phases. | 67 | The above abstraction prevents unnecessary pain during transitional phases. |
65 | If the name of the field changes or is removed, then every downstream driver | 68 | If it were not done this way, then when a field was renamed or removed, every |
66 | will break. On the other hand, if only the bus layer (and not the device | 69 | downstream driver would break. On the other hand, if only the bus layer |
67 | layer) accesses struct device, it is only that layer that needs to change. | 70 | (and not the device layer) accesses the struct device, it is only the bus |
71 | layer that needs to change. | ||
68 | 72 | ||
69 | 73 | ||
70 | User Interface | 74 | User Interface |
@@ -73,15 +77,27 @@ User Interface | |||
73 | By virtue of having a complete hierarchical view of all the devices in the | 77 | By virtue of having a complete hierarchical view of all the devices in the |
74 | system, exporting a complete hierarchical view to userspace becomes relatively | 78 | system, exporting a complete hierarchical view to userspace becomes relatively |
75 | easy. This has been accomplished by implementing a special purpose virtual | 79 | easy. This has been accomplished by implementing a special purpose virtual |
76 | file system named sysfs. It is hence possible for the user to mount the | 80 | file system named sysfs. |
77 | whole sysfs filesystem anywhere in userspace. | 81 | |
82 | Almost all mainstream Linux distros mount this filesystem automatically; you | ||
83 | can see some variation of the following in the output of the "mount" command: | ||
84 | |||
85 | $ mount | ||
86 | ... | ||
87 | none on /sys type sysfs (rw,noexec,nosuid,nodev) | ||
88 | ... | ||
89 | $ | ||
90 | |||
91 | The auto-mounting of sysfs is typically accomplished by an entry similar to | ||
92 | the following in the /etc/fstab file: | ||
93 | |||
94 | none /sys sysfs defaults 0 0 | ||
78 | 95 | ||
79 | This can be done permanently by providing the following entry into the | 96 | or something similar in the /lib/init/fstab file on Debian-based systems: |
80 | /etc/fstab (under the provision that the mount point does exist, of course): | ||
81 | 97 | ||
82 | none /sys sysfs defaults 0 0 | 98 | none /sys sysfs nodev,noexec,nosuid 0 0 |
83 | 99 | ||
84 | Or by hand on the command line: | 100 | If sysfs is not automatically mounted, you can always do it manually with: |
85 | 101 | ||
86 | # mount -t sysfs sysfs /sys | 102 | # mount -t sysfs sysfs /sys |
87 | 103 | ||
diff --git a/Documentation/filesystems/debugfs.txt b/Documentation/filesystems/debugfs.txt index ed52af60c2d8..742cc06e138f 100644 --- a/Documentation/filesystems/debugfs.txt +++ b/Documentation/filesystems/debugfs.txt | |||
@@ -73,8 +73,8 @@ the following functions can be used instead: | |||
73 | struct dentry *parent, u16 *value); | 73 | struct dentry *parent, u16 *value); |
74 | struct dentry *debugfs_create_x32(const char *name, mode_t mode, | 74 | struct dentry *debugfs_create_x32(const char *name, mode_t mode, |
75 | struct dentry *parent, u32 *value); | 75 | struct dentry *parent, u32 *value); |
76 | 76 | struct dentry *debugfs_create_x64(const char *name, mode_t mode, | |
77 | Note that there is no debugfs_create_x64(). | 77 | struct dentry *parent, u64 *value); |
78 | 78 | ||
79 | These functions are useful as long as the developer knows the size of the | 79 | These functions are useful as long as the developer knows the size of the |
80 | value to be exported. Some types can have different widths on different | 80 | value to be exported. Some types can have different widths on different |
diff --git a/Documentation/ja_JP/SubmittingPatches b/Documentation/ja_JP/SubmittingPatches index f107c834d242..97f78dd0c085 100644 --- a/Documentation/ja_JP/SubmittingPatches +++ b/Documentation/ja_JP/SubmittingPatches | |||
@@ -11,16 +11,18 @@ for non English (read: Japanese) speakers and is not intended as a | |||
11 | fork. So if you have any comments or updates of this file, please try | 11 | fork. So if you have any comments or updates of this file, please try |
12 | to update the original English file first. | 12 | to update the original English file first. |
13 | 13 | ||
14 | Last Updated: 2007/10/24 | 14 | Last Updated: 2011/06/09 |
15 | |||
15 | ================================== | 16 | ================================== |
16 | これは、 | 17 | これは、 |
17 | linux-2.6.23/Documentation/SubmittingPatches の和訳 | 18 | linux-2.6.39/Documentation/SubmittingPatches の和訳 |
18 | です。 | 19 | です。 |
19 | 翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ > | 20 | 翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ > |
20 | 翻訳日: 2007/10/17 | 21 | 翻訳日: 2011/06/09 |
21 | 翻訳者: Keiichi Kii <k-keiichi at bx dot jp dot nec dot com> | 22 | 翻訳者: Keiichi Kii <k-keiichi at bx dot jp dot nec dot com> |
22 | 校正者: Masanari Kobayashi さん <zap03216 at nifty dot ne dot jp> | 23 | 校正者: Masanari Kobayashi さん <zap03216 at nifty dot ne dot jp> |
23 | Matsukura さん <nbh--mats at nifty dot com> | 24 | Matsukura さん <nbh--mats at nifty dot com> |
25 | Takeshi Hamasaki さん <hmatrjp at users dot sourceforge dot jp> | ||
24 | ================================== | 26 | ================================== |
25 | 27 | ||
26 | Linux カーネルに変更を加えるための Howto | 28 | Linux カーネルに変更を加えるための Howto |
@@ -97,7 +99,7 @@ Quilt: | |||
97 | http://savannah.nongnu.org/projects/quilt | 99 | http://savannah.nongnu.org/projects/quilt |
98 | 100 | ||
99 | Andrew Morton's patch scripts: | 101 | Andrew Morton's patch scripts: |
100 | http://userweb.kernel.org/~akpm/stuff/tpp.txt | 102 | http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz |
101 | このリンクの先のスクリプトの代わりとして、quilt がパッチマネジメント | 103 | このリンクの先のスクリプトの代わりとして、quilt がパッチマネジメント |
102 | ツールとして推奨されています(上のリンクを見てください)。 | 104 | ツールとして推奨されています(上のリンクを見てください)。 |
103 | 105 | ||
@@ -109,9 +111,25 @@ http://userweb.kernel.org/~akpm/stuff/tpp.txt | |||
109 | 「ドライバー X に対するバグフィックス」あるいは「このパッチはサブシス | 111 | 「ドライバー X に対するバグフィックス」あるいは「このパッチはサブシス |
110 | テム X に対する更新を含んでいます。どうか取り入れてください。」などです。 | 112 | テム X に対する更新を含んでいます。どうか取り入れてください。」などです。 |
111 | 113 | ||
114 | パッチの説明を Linux カーネルのソースコードマネジメントシステム「 git 」の | ||
115 | コミットログとして簡単に引用できる形で書けば、メンテナから感謝されるでしょう。 | ||
116 | 以下の #15 を見てください。 | ||
117 | |||
112 | 説明が長くなりだしたのであれば、おそらくそれはパッチを分ける必要がある | 118 | 説明が長くなりだしたのであれば、おそらくそれはパッチを分ける必要がある |
113 | という兆候です。次の #3 を見てください。 | 119 | という兆候です。次の #3 を見てください。 |
114 | 120 | ||
121 | パッチ(シリーズ)を(再)投稿する時、十分なパッチの説明とそのパッチが必要な理由を | ||
122 | パッチに含めてください。ただ「これはパッチ(シリーズ)のバージョン N」とだけ | ||
123 | 書かないでください。そして、パッチをマージする人にパッチの説明を探させそれを | ||
124 | パッチに追記させるため、過去のバージョンのパッチやそのパッチの URL を参照する | ||
125 | 手間をかけさせないでください。 | ||
126 | つまり、パッチシリーズとその説明は一緒にあるべきです。これはパッチをマージする | ||
127 | 人、レビューする人、どちらのためにもなります。レビューする人の中には、おそらく | ||
128 | 過去のバージョンのパッチを受け取ってもいない人がいます。 | ||
129 | |||
130 | 登録済みのバグエントリを修正するパッチであれば、そのバグエントリを示すバグ ID | ||
131 | や URL を明記してください。 | ||
132 | |||
115 | 3) パッチの分割 | 133 | 3) パッチの分割 |
116 | 134 | ||
117 | 意味のあるひとまとまりごとに変更を個々のパッチファイルに分けてください。 | 135 | 意味のあるひとまとまりごとに変更を個々のパッチファイルに分けてください。 |
@@ -141,7 +159,7 @@ http://userweb.kernel.org/~akpm/stuff/tpp.txt | |||
141 | 拒否されるでしょう。 | 159 | 拒否されるでしょう。 |
142 | 160 | ||
143 | あなたはパッチを投稿する前に最低限パッチスタイルチェッカー | 161 | あなたはパッチを投稿する前に最低限パッチスタイルチェッカー |
144 | ( scripts/patchcheck.pl )を利用してパッチをチェックすべきです。 | 162 | ( scripts/checkpatch.pl )を利用してパッチをチェックすべきです。 |
145 | もしパッチに違反がのこっているならば、それらの全てについてあなたは正当な | 163 | もしパッチに違反がのこっているならば、それらの全てについてあなたは正当な |
146 | 理由を示せるようにしておく必要があります。 | 164 | 理由を示せるようにしておく必要があります。 |
147 | 165 | ||
@@ -192,13 +210,13 @@ VGER.KERNEL.ORG でホスティングされているメーリングリストの | |||
192 | 情報がマニュアルページの中に入ってくるように、変更が起きたという | 210 | 情報がマニュアルページの中に入ってくるように、変更が起きたという |
193 | 通知を送ってください。 | 211 | 通知を送ってください。 |
194 | 212 | ||
195 | たとえ、メンテナが #4 で反応がなかったとしても、メンテナのコードに変更を | 213 | たとえ、メンテナが #5 で反応がなかったとしても、メンテナのコードに変更を |
196 | 加えたときには、いつもメンテナに CC するのを忘れないようにしてください。 | 214 | 加えたときには、いつもメンテナに CC するのを忘れないようにしてください。 |
197 | 215 | ||
198 | 小さなパッチであれば、Adrian Bunk 理している Trivial Patch Monkey | 216 | 小さなパッチであれば、Trivial Patch Monkey(ちとパッチを集めいる) |
199 | (ちょっとしたパッチを集めている)<trivial@kernel.org>に CC してもいい | 217 | <trivial@kernel.org>に CC してもいいです。その現管理者については MAINTAINERS |
200 | 。ちょっとしたパッチとは以下のルールのどれか1つを満たしていなけ | 218 | ァイルを見さいちょっとしたパッチとは以下のルールのどれか1つを満たして |
201 | ればなりません。 | 219 | なけばなりません。 |
202 | ・ドキュメントのスペルミスの修正 | 220 | ・ドキュメントのスペルミスの修正 |
203 | ・grep(1) コマンドによる検索を困難にしているスペルの修正 | 221 | ・grep(1) コマンドによる検索を困難にしているスペルの修正 |
204 | ・コンパイル時の警告の修正(無駄な警告が散乱することは好ましくないた | 222 | ・コンパイル時の警告の修正(無駄な警告が散乱することは好ましくないた |
@@ -210,7 +228,6 @@ VGER.KERNEL.ORG でホスティングされているメーリングリストの | |||
210 | ・移植性のないコードから移植性のあるコードへの置き換え(小さい範囲で | 228 | ・移植性のないコードから移植性のあるコードへの置き換え(小さい範囲で |
211 | あればアーキテクチャ特有のことでも他の人がコピーできます) | 229 | あればアーキテクチャ特有のことでも他の人がコピーできます) |
212 | ・作者やメンテナによる修正(すなわち patch monkey の再転送モード) | 230 | ・作者やメンテナによる修正(すなわち patch monkey の再転送モード) |
213 | EMAIL: <trivial@kernel.org> | ||
214 | 231 | ||
215 | 7) MIME やリンクや圧縮ファイルや添付ファイルではなくプレインテキストのみ | 232 | 7) MIME やリンクや圧縮ファイルや添付ファイルではなくプレインテキストのみ |
216 | 233 | ||
@@ -233,26 +250,15 @@ MIME 形式の添付ファイルは Linus に手間を取らせることにな | |||
233 | 例外:お使いの電子メールクライアントがパッチをめちゃくちゃにするので | 250 | 例外:お使いの電子メールクライアントがパッチをめちゃくちゃにするので |
234 | あれば、誰かが MIME 形式のパッチを再送するよう求めるかもしれません。 | 251 | あれば、誰かが MIME 形式のパッチを再送するよう求めるかもしれません。 |
235 | 252 | ||
236 | 警告: Mozilla のような特定の電子メールクライアントは電子メールの | 253 | 余計な変更を加えずにあなたのパッチを送信するための電子メールクライアントの設定 |
237 | ヘッダに以下のものを付加して送ります。 | 254 | のヒントについては Documentation/email-clients.txt を参照してください。 |
238 | ---- message header ---- | ||
239 | Content-Type: text/plain; charset=us-ascii; format=flowed | ||
240 | ---- message header ---- | ||
241 | 問題は、「 format=flowed 」が付いた電子メールを特定の受信側の電子メール | ||
242 | クライアントがタブをスペースに置き換えるというような変更をすることです。 | ||
243 | したがって送られてきたパッチは壊れているように見えるでしょう。 | ||
244 | |||
245 | これを修正するには、mozilla の defaults/pref/mailnews.js ファイルを | ||
246 | 以下のように修正します。 | ||
247 | pref("mailnews.send_plaintext_flowed", false); // RFC 2646======= | ||
248 | pref("mailnews.display.disable_format_flowed_support", true); | ||
249 | 255 | ||
250 | 8) 電子メールのサイズ | 256 | 8) 電子メールのサイズ |
251 | 257 | ||
252 | パッチを Linus へ送るときは常に #7 の手順に従ってください。 | 258 | パッチを Linus へ送るときは常に #7 の手順に従ってください。 |
253 | 259 | ||
254 | 大きなパッチはメーリングリストやメンテナにとって不親切です。パッチが | 260 | 大きなパッチはメーリングリストやメンテナにとって不親切です。パッチが |
255 | 未圧縮で 40KB を超えるようであるなら、インターネット上のアクセス可能な | 261 | 未圧縮で 300KB を超えるようであるなら、インターネット上のアクセス可能な |
256 | サーバに保存し、保存場所を示す URL を伝えるほうが適切です。 | 262 | サーバに保存し、保存場所を示す URL を伝えるほうが適切です。 |
257 | 263 | ||
258 | 9) カーネルバージョンの明記 | 264 | 9) カーネルバージョンの明記 |
@@ -324,7 +330,7 @@ Linus や LKML への大量の電子メールのために、サブジェクト | |||
324 | (c) 本寄与は(a)、(b)、(c)を証明する第3者から私へ直接提供された | 330 | (c) 本寄与は(a)、(b)、(c)を証明する第3者から私へ直接提供された |
325 | ものであり、私はそれに変更を加えていない。 | 331 | ものであり、私はそれに変更を加えていない。 |
326 | 332 | ||
327 | (d) 私はこのプロジェクトと本寄与が公のものであることに理解及び同意す | 333 | (d) 私はこのプロジェクトと本寄与が公のものであることに理解及び同意す |
328 | る。同時に、関与した記録(投稿の際の全ての個人情報と sign-off を | 334 | る。同時に、関与した記録(投稿の際の全ての個人情報と sign-off を |
329 | 含む)が無期限に保全されることと、当該プロジェクト又は関連する | 335 | 含む)が無期限に保全されることと、当該プロジェクト又は関連する |
330 | オープンソースライセンスに沿った形で再配布されることに理解及び | 336 | オープンソースライセンスに沿った形で再配布されることに理解及び |
@@ -340,7 +346,51 @@ Linus や LKML への大量の電子メールのために、サブジェクト | |||
340 | 無視されますが、あなたはそのタグを社内の手続きに利用したり、sign-off に特別 | 346 | 無視されますが、あなたはそのタグを社内の手続きに利用したり、sign-off に特別 |
341 | な情報を示したりすることができます。 | 347 | な情報を示したりすることができます。 |
342 | 348 | ||
343 | 13) いつ Acked-by: を使うのか | 349 | あなたがサブシステムまたはブランチのメンテナであれば、受け取ったパッチを自身の |
350 | ツリーにマージするために、わずかに変更が必要となる場合があります。なぜなら | ||
351 | あなたのツリーの中のコードと投稿者のツリーの中のコードは同一ではないためです。 | ||
352 | もし、あなたが厳密に上記ルール(c)にこだわるのであれば、投稿者に再度差分を | ||
353 | とるよう依頼すべきです。しかし、これは時間とエネルギーを非生産的に浪費する | ||
354 | ことになります。ルール(b)はあなたにコードを修正する権利を与えてくれます。 | ||
355 | しかし、投稿者のコードを修正し、その修正によるバグを投稿者に押し付けてしまう | ||
356 | ことはとても失礼なことです。この問題を解決するために、末尾の投稿者の | ||
357 | Signed-off-by とあなたがその末尾に追加する Signed-off-by の間に、修正を | ||
358 | 加えたことを示す1行を追加することが推奨されています。 | ||
359 | (その1行の書き方に)決まりはありませんが、大括弧の中に電子メールアドレスや氏名 | ||
360 | と修正内容を記載するやり方は目につきやすく、最終段階での変更の責任があなたに | ||
361 | あることを明確にするのに十分な方法のようです。例えば、 | ||
362 | |||
363 | Signed-off-by: Random J Developer <random@developer.example.org> | ||
364 | [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h] | ||
365 | Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org> | ||
366 | |||
367 | あなたが安定版のブランチを管理しており、作成者のクレジット、変更の追跡、 | ||
368 | 修正のマージ、と同時に苦情からの投稿者の保護を行いたい場合、この慣習は特に | ||
369 | 有用となります。いかなる事情があってもチェンジログに出てくる作成者の | ||
370 | アイデンティティ情報(From ヘッダ)は変更できないことに注意してください。 | ||
371 | |||
372 | バックポートする人のための特別な注意事項。追跡を容易に行うために、コミット | ||
373 | メッセージのトップ(サブジェクト行のすぐ後)にパッチの起源を示す情報を記述する | ||
374 | ことは一般的で有用な慣習です。例えば、これは 2.6-stable ツリーでの一例です。 | ||
375 | |||
376 | Date: Tue May 13 19:10:30 2008 +0000 | ||
377 | |||
378 | SCSI: libiscsi regression in 2.6.25: fix nop timer handling | ||
379 | |||
380 | commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream | ||
381 | |||
382 | そして、これは 2.4 ツリーでの一例です。 | ||
383 | |||
384 | Date: Tue May 13 22:12:27 2008 +0200 | ||
385 | |||
386 | wireless, airo: waitbusy() won't delay | ||
387 | |||
388 | [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a] | ||
389 | |||
390 | どんな形式であれ、この情報はあなたのツリーを追跡する人やあなたのツリーのバグを | ||
391 | 解決しようとしている人にとって価値のある支援となります。 | ||
392 | |||
393 | 13) いつ Acked-by: と Cc: を使うのか | ||
344 | 394 | ||
345 | 「 Signed-off-by: 」タグはその署名者がパッチの開発に関わっていたことやパッチ | 395 | 「 Signed-off-by: 」タグはその署名者がパッチの開発に関わっていたことやパッチ |
346 | の伝播パスにいたことを示しています。 | 396 | の伝播パスにいたことを示しています。 |
@@ -354,7 +404,7 @@ Linus や LKML への大量の電子メールのために、サブジェクト | |||
354 | 404 | ||
355 | Acked-by: は Signed-off-by: のように公式なタグではありません。それはメンテナが | 405 | Acked-by: は Signed-off-by: のように公式なタグではありません。それはメンテナが |
356 | 少なくともパッチをレビューし、同意を示しているという記録です。そのような | 406 | 少なくともパッチをレビューし、同意を示しているという記録です。そのような |
357 | ことからパッチ統合者がメンテナの「うん、良いと思うよ」という発言を | 407 | ことからパッチマージ人メンテナの「うん、良いと思うよ」という発言を |
358 | Acked-by: へ置き換えることがあります。 | 408 | Acked-by: へ置き換えることがあります。 |
359 | 409 | ||
360 | Acked-by: が必ずしもパッチ全体の承認を示しているわけではありません。例えば、 | 410 | Acked-by: が必ずしもパッチ全体の承認を示しているわけではありません。例えば、 |
@@ -364,7 +414,62 @@ Acked-by: が必ずしもパッチ全体の承認を示しているわけでは | |||
364 | この点は、ご自分で判断してください。(その Acked-by: が)疑わしい場合は、 | 414 | この点は、ご自分で判断してください。(その Acked-by: が)疑わしい場合は、 |
365 | メーリングリストアーカイブの中の大元の議論を参照すべきです。 | 415 | メーリングリストアーカイブの中の大元の議論を参照すべきです。 |
366 | 416 | ||
367 | 14) 標準的なパッチのフォーマット | 417 | パッチにコメントする機会を持っていたが、その時にコメントしなかった人がいれば、 |
418 | その人を指す「Cc:」タグを任意で追加してもかまいません。これは指定された人からの | ||
419 | 明確なアクションなしに付与できる唯一のタグです。 | ||
420 | このタグはパッチに関心があると思われる人達がそのパッチの議論に含まれていたこと | ||
421 | を明文化します。 | ||
422 | |||
423 | 14) Reported-by と Tested-by: と Reviewed-by: の利用 | ||
424 | |||
425 | 他の誰かによって報告された問題を修正するパッチであれば、問題報告者という寄与を | ||
426 | クレジットするために、Reported-by: タグを追加することを検討してください。 | ||
427 | こまめにバグ報告者をクレジットしていくことで、うまくいけばその人たちが将来再び | ||
428 | コミュニティの力となってくれるでしょう。 | ||
429 | ただし、報告者の許可無くこのタグを追加しないように注意してください。特に、 | ||
430 | 問題が公の場で報告されていなかったのであれば。 | ||
431 | |||
432 | Tested-by: タグはタグで指定された人によって(ある環境下で)パッチのテストに成功 | ||
433 | していることを示します。このタグはメンテナにテストが実施済みであることを | ||
434 | 知らせ、将来の関連パッチのテスト協力者を見つける方法を提供し、テスト実施者に | ||
435 | 対するクレジットを保証します。 | ||
436 | |||
437 | Reviewed-by: タグは、それとは異なり、下記のレビューア宣言の下にレビューされ、 | ||
438 | 受け入れ可能とみなされたパッチであることを示します。 | ||
439 | |||
440 | レビューアによる監督宣言 | ||
441 | |||
442 | 私は Reviewed-by: タグを提示することによって、以下のことを明言する。 | ||
443 | |||
444 | (a) 私はメインラインカーネルへの統合に向け、その妥当性及び「即応性 | ||
445 | (訳注)」を検証し、技術的側面からパッチをレビュー済みである。 | ||
446 | |||
447 | 訳注: | ||
448 | 「即応性」の原文は "readiness"。 | ||
449 | パッチが十分な品質を持っており、メインラインカーネルへの統合を即座に | ||
450 | 行うことができる状態であるかどうかを "readiness" という単語で表現 | ||
451 | している。 | ||
452 | |||
453 | (b) パッチに関するあらゆる問題、懸念、あるいは、疑問は投稿者へ伝達済み | ||
454 | である。私はそれらのコメントに対する投稿者の返答に満足している。 | ||
455 | |||
456 | (c) 投稿に伴い改良されるコードがある一方で、現時点で、私は(1)それが | ||
457 | カーネルにとって価値のある変更であること、そして、(2)統合に際して | ||
458 | 議論になり得るような問題はないものと確信している。 | ||
459 | |||
460 | (d) 私はパッチをレビューし適切であると確信している一方で、あらゆる | ||
461 | 状況においてその宣言した目的や機能が正しく実現することに関して、 | ||
462 | いかなる保証もしない(特にどこかで明示しない限り)。 | ||
463 | |||
464 | Reviewd-by タグはそのパッチがカーネルに対して適切な修正であって、深刻な技術的 | ||
465 | 問題を残していないという意見の宣言です。興味のあるレビューアは誰でも(レビュー | ||
466 | 作業を終えたら)パッチに対して Reviewed-by タグを提示できます。このタグは | ||
467 | レビューアの寄与をクレジットする働き、レビューの進捗の度合いをメンテナに | ||
468 | 知らせる働きを持ちます。そのパッチの領域に詳しく、そして、しっかりとした | ||
469 | レビューを実施したレビューアによって提供される時、Reviewed-by: タグがあなたの | ||
470 | パッチをカーネルにマージする可能性を高めるでしょう。 | ||
471 | |||
472 | 15) 標準的なパッチのフォーマット | ||
368 | 473 | ||
369 | 標準的なパッチのサブジェクトは以下のとおりです。 | 474 | 標準的なパッチのサブジェクトは以下のとおりです。 |
370 | 475 | ||
@@ -396,18 +501,37 @@ Acked-by: が必ずしもパッチ全体の承認を示しているわけでは | |||
396 | 電子メールのサブジェクト内のサブシステム表記は、パッチが適用される | 501 | 電子メールのサブジェクト内のサブシステム表記は、パッチが適用される |
397 | 分野またはサブシステムを識別できるようにすべきです。 | 502 | 分野またはサブシステムを識別できるようにすべきです。 |
398 | 503 | ||
399 | 電子メールのサブジェクトの「概要い回しはそのパッチの概要を正確 | 504 | 電子メールのサブジェクトの「summary phrase」はそのパッチの概要を正確 |
400 | に表現しなければなりません。「概要い回しをファイル名にしてはい | 505 | に表現しなければなりません。「summary phrase」をファイル名にしてはい |
401 | けません。一連ッチ中でそれぞれのパッチは同じ「概要い回しを | 506 | けません。パッチシリーズ中でそれぞれのパッチは同じ「summary phrase」を |
402 | 使ってはいけません(「一連ッチ」とは順序付けられた関連のある複数の | 507 | 使ってはいけません(「パッチリーズとは順序付けられた関連のある複数の |
403 | パッチ群です)。 | 508 | パッチ群です)。 |
404 | 509 | ||
405 | あなたの電子メールの「概要の言い回し」がそのパッチにとって世界で唯 | 510 | あなたの電子メールの「summary phrase」がそのパッチにとって世界で唯一の識別子に |
406 | 一の識別子になるように心がけてください。「概要の言い回し」は git の | 511 | なるように心がけてください。「summary phrase」は git のチェンジログの中へ |
407 | チェンジログの中へずっと伝播していきます。「概要の言い回し」は、開 | 512 | ずっと伝播していきます。「summary phrase」は、開発者が後でパッチを参照する |
408 | 発者が後でパッチを参照するために議論の中で利用するかもしれません。 | 513 | ために議論の中で利用するかもしれません。 |
409 | 人々はそのパッチに関連した議論を読むために「概要の言い回し」を使って | 514 | 人々はそのパッチに関連した議論を読むために「summary phrase」を使って google で |
410 | google で検索したがるでしょう。 | 515 | 検索したがるでしょう。それはまた2、3ヶ月あとで、人々が「gitk」や |
516 | 「git log --oneline」のようなツールを使用して何千ものパッチに目を通す時、 | ||
517 | 唯一目にとまる情報となるでしょう。 | ||
518 | |||
519 | これらの理由のため、「summary phrase」はなぜパッチが必要であるか、パッチが何を | ||
520 | 変更するかの2つの情報をせいぜい70〜75文字で表現していなければなりません。 | ||
521 | 「summary phrase」は簡潔であり説明的である表現を目指しつつ、うまく | ||
522 | まとめられている概要となるべきです。 | ||
523 | |||
524 | 「summary phrase」は「Subject: [PATCH tag] <summary phrase>」のように、 | ||
525 | 大括弧で閉じられたタグを接頭辞として付加してもかまいません。このタグは | ||
526 | 「summary phrase」の一部とは考えませんが、パッチをどのように取り扱うべきかを | ||
527 | 表現します。 | ||
528 | 一般的には「v1, v2, v3」のようなバージョン情報を表すタグ(過去のパッチに対する | ||
529 | コメントを反映するために複数のバージョンのパッチが投稿されているのであれば)、 | ||
530 | 「RFC」のようなコメントを要求するタグが挙げられます。パッチシリーズとして4つの | ||
531 | パッチがあれば、個々のパッチに「1/4, 2/4, 3/4, 4/4」のように番号を付けても | ||
532 | かまいません。これは開発者がパッチを適用する順番を確実に把握するためです。 | ||
533 | そして、開発者がパッチシリーズの中のすべてのパッチをもらさずレビュー或いは | ||
534 | 適用するのを保証するためです。 | ||
411 | 535 | ||
412 | サブジェクトの例を二つ | 536 | サブジェクトの例を二つ |
413 | 537 | ||
@@ -426,7 +550,12 @@ google で検索したがるでしょう。 | |||
426 | 550 | ||
427 | 説明本体は無期限のソースのチェンジログにコミットされます。なので、説明 | 551 | 説明本体は無期限のソースのチェンジログにコミットされます。なので、説明 |
428 | 本体はそのパッチに至った議論の詳細を忘れているある程度の技量を持っている人 | 552 | 本体はそのパッチに至った議論の詳細を忘れているある程度の技量を持っている人 |
429 | がその詳細を思い出すことができるものでなければなりません。 | 553 | がその詳細を思い出すことができるものでなければなりません。パッチが対処する |
554 | 障害の症状(カーネルログメッセージや oops メッセージ等)を記載することは問題に | ||
555 | 対処可能なパッチを求めてコミットログを検索する人々にとって特に有用です。 | ||
556 | パッチがコンパイル問題を解決するのであれば、そのパッチを探している人が見つける | ||
557 | ことができる情報だけで十分であり、コンパイル時の全てのエラーを含める必要は | ||
558 | ありません。「summary phrase」と同様に、簡潔であり説明的であることが重要です。 | ||
430 | 559 | ||
431 | 「 --- 」マーカー行はパッチ処理ツールに対して、チェンジログメッセージの終端 | 560 | 「 --- 」マーカー行はパッチ処理ツールに対して、チェンジログメッセージの終端 |
432 | 部分を認識させるという重要な役目を果たします。 | 561 | 部分を認識させるという重要な役目を果たします。 |
@@ -436,14 +565,46 @@ google で検索したがるでしょう。 | |||
436 | 追加され何行消されたかを示すものです。diffstat コマンドは特に大きなパッチに | 565 | 追加され何行消されたかを示すものです。diffstat コマンドは特に大きなパッチに |
437 | おいて役立ちます。その時点でだけ又はメンテナにとってのみ関係のあるコメント | 566 | おいて役立ちます。その時点でだけ又はメンテナにとってのみ関係のあるコメント |
438 | は無期限に保存されるチェンジログにとって適切ではありません。そのため、この | 567 | は無期限に保存されるチェンジログにとって適切ではありません。そのため、この |
439 | ようなコメントもマーカー行の後に書かれるべきです。ファイル名はカーネルソー | 568 | ようなコメントもマーカー行の後に書かれるべきです。 |
440 | スツリーのトップディレクトリからの表記でリストされるため、横方向のスペース | 569 | このようなコメントの良い例として、v1 と v2 のバージョン間で何が変更されたかを |
441 | をとり過ぎないように、diffstat コマンドにオプション「 -p 1 -w 70 」を指定し | 570 | 表す「パッチの変更履歴」が挙げられます。 |
442 | てください(インデントを含めてちょうど80列に合うでしょう)。 | 571 | |
572 | 「 --- 」マーカー行の後に diffstat コマンドの結果を含めるのであれば、ファイル | ||
573 | 名はカーネルソースツリーのトップディレクトリからの表記で列記されるため、横方向 | ||
574 | のスペースをとり過ぎないように、diffstat コマンドにオプション「 -p 1 -w 70 」 | ||
575 | を指定してください(インデントを含めてちょうど80列に合うでしょう)。 | ||
443 | 576 | ||
444 | 適切なパッチのフォーマットの詳細についてはセクション3の参考文献を参照して | 577 | 適切なパッチのフォーマットの詳細についてはセクション3の参考文献を参照して |
445 | ください。 | 578 | ください。 |
446 | 579 | ||
580 | 16) 「git pull」要求の送り方(Linus の電子メールから) | ||
581 | |||
582 | 間違ったブランチから引っ張るのを防ぐために、git リポジトリのアドレスと | ||
583 | ブランチ名を同じ行に1行で記載してください。そうすることで、3回の連続クリック | ||
584 | で全て選択できます。 | ||
585 | |||
586 | 正しい形式は下記の通りです。 | ||
587 | |||
588 | "Please pull from | ||
589 | |||
590 | git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus | ||
591 | |||
592 | to get these changes:" | ||
593 | |||
594 | その結果、アドレスを自分自身でタイピングして間違えることはなくなります(実際に、 | ||
595 | 何度か間違ったブランチから引っ張ってきてしまい、その時に diffstat の結果を | ||
596 | 検証して間違っていることに気づいたことがあります。どこから何を引っ張るべきかを | ||
597 | 「探したり」、正しいブランチ名かどうかを重ねてチェックしたりする必要が | ||
598 | なくなればより快適になるでしょう)。 | ||
599 | |||
600 | diffstat の結果を生成するために「 git diff -M --stat --summary 」を使って | ||
601 | ください。-M オプションはファイル名の変更を検知でき、--summary オプションは | ||
602 | 新規ファイル、削除されたファイル、名前が変更されたファイルの概要を生成します。 | ||
603 | |||
604 | -M オプション(ファイル名の変更検知)を指定すると、diffstat の結果はかなり | ||
605 | 異なってきます。git は大規模な変更(追加と削除のペア)をファイル名の変更と | ||
606 | 判断するためです。 | ||
607 | |||
447 | ------------------------------------ | 608 | ------------------------------------ |
448 | セクション2 - ヒントとTIPSと小技 | 609 | セクション2 - ヒントとTIPSと小技 |
449 | ------------------------------------ | 610 | ------------------------------------ |
@@ -459,7 +620,7 @@ google で検索したがるでしょう。 | |||
459 | も逸脱していると、レビューやコメントなしに受け取ってもらえないかもし | 620 | も逸脱していると、レビューやコメントなしに受け取ってもらえないかもし |
460 | れません。 | 621 | れません。 |
461 | 622 | ||
462 | 唯一の特筆すべき例外は、コードをあるファイルから別のファイルに移動 | 623 | 特筆すべき例外は、コードをあるファイルから別のファイルに移動 |
463 | するときです。この場合、コードを移動するパッチでは、移動されるコード | 624 | するときです。この場合、コードを移動するパッチでは、移動されるコード |
464 | に関して移動以外の変更を一切加えるべきではありません。これにより、 | 625 | に関して移動以外の変更を一切加えるべきではありません。これにより、 |
465 | コードの移動とあなたが行ったコードの修正を明確に区別できるようにな | 626 | コードの移動とあなたが行ったコードの修正を明確に区別できるようにな |
@@ -553,4 +714,11 @@ Kernel Documentation/CodingStyle: | |||
553 | 714 | ||
554 | Linus Torvalds's mail on the canonical patch format: | 715 | Linus Torvalds's mail on the canonical patch format: |
555 | <http://lkml.org/lkml/2005/4/7/183> | 716 | <http://lkml.org/lkml/2005/4/7/183> |
717 | |||
718 | Andi Kleen, "On submitting kernel patches" | ||
719 | Some strategies to get difficult or controversial changes in. | ||
720 | http://halobates.de/on-submitting-patches.pdf | ||
721 | |||
556 | -- | 722 | -- |
723 | |||
724 | |||
diff --git a/Documentation/zh_CN/email-clients.txt b/Documentation/zh_CN/email-clients.txt index 5d65e323d060..b9a1a3e6c78d 100644 --- a/Documentation/zh_CN/email-clients.txt +++ b/Documentation/zh_CN/email-clients.txt | |||
@@ -1,4 +1,4 @@ | |||
1 | 锘?Chinese translated version of Documentation/email-clients.txt | 1 | Chinese translated version of Documentation/email-clients.txt |
2 | 2 | ||
3 | If you have any comment or update to the content, please contact the | 3 | If you have any comment or update to the content, please contact the |
4 | original document maintainer directly. However, if you have a problem | 4 | original document maintainer directly. However, if you have a problem |
@@ -8,203 +8,203 @@ or if there is a problem with the translation. | |||
8 | 8 | ||
9 | Chinese maintainer: Harry Wei <harryxiyou@gmail.com> | 9 | Chinese maintainer: Harry Wei <harryxiyou@gmail.com> |
10 | --------------------------------------------------------------------- | 10 | --------------------------------------------------------------------- |
11 | Documentation/email-clients.txt ???涓?????? | 11 | Documentation/email-clients.txt 中翻译 |
12 | 12 | ||
13 | 濡????????璁????存??????????????璇?存?ヨ??诲???????缁存?よ?????????????? | 13 | 果评论更新本文内,请联档的维如果你使文 |
14 | 浜ゆ???????????锛?????ュ??涓???????缁??????┿??????????????颁????????????? | 14 | 交困难的话也以向中文者本译新不时者 |
15 | 璇?瀛???ㄩ??棰??????????缁存?????? | 15 | 译存在题,请中护 |
16 | 16 | ||
17 | ???????存???锛? ??濞? Harry Wei <harryxiyou@gmail.com> | 17 | 中者: 贾威威 Harry Wei <harryxiyou@gmail.com> |
18 | ???????昏?????锛? 惧??? Harry Wei <harryxiyou@gmail.com> | 18 | 中译者: 贾威威 Harry Wei <harryxiyou@gmail.com> |
19 | ?????????¤?????锛? Yinglin Luan <synmyth@gmail.com> | 19 | 中版校译者: Yinglin Luan <synmyth@gmail.com> |
20 | Xiaochen Wang <wangxiaochen0@gmail.com> | 20 | Xiaochen Wang <wangxiaochen0@gmail.com> |
21 | yaxinsn <yaxinsn@163.com> | 21 | yaxinsn <yaxinsn@163.com> |
22 | 22 | ||
23 | ヤ??烘?f?? | 23 | 以下为 |
24 | --------------------------------------------------------------------- | 24 | --------------------------------------------------------------------- |
25 | 25 | ||
26 | Linux???跺????????℃?? | 26 | Linux邮件客端信 |
27 | ====================================================================== | 27 | ====================================================================== |
28 | 28 | ||
29 | ?????????? | 29 | 普通配 |
30 | ---------------------------------------------------------------------- | 30 | ---------------------------------------------------------------------- |
31 | Linux?????歌ˉ涓???????杩????浠惰?????浜ょ??锛????濂芥??琛ヤ??浣?涓洪??浠朵????????宓?????????????浜?缁存?よ?? | 31 | Linux内核补丁是通过邮件被提交的,最好把补丁作为邮件体的内嵌文本。有些维护者 |
32 | ??ユ?堕????????????????瀹?煎???璇ユ??"text/plain"?????惰??????????????涓????????锛? | 32 | 收附件,但是附件的内应"text/plain"。然而,件一般不, |
33 | ???涓???浣ˉ涓????寮???ㄩ??????????涓??????????伴?俱?? | 33 | 因使丁引分在评论中的很难。 |
34 | 34 | ||
35 | ??ㄦ?ュ?????Linux?????歌ˉ涓???????浠跺?㈡?风????ㄥ?????琛ヤ????跺??璇ュ??浜?????????????濮???舵?????渚?濡?锛? | 35 | 用来发送Linux内核补丁的邮件客户端在发送补丁时应该处于文本的原始状态。例如, |
36 | ???????????????????ゅ?????????硷???????????ㄦ???琛?????澶??????俱?? | 36 | 他们不能变者除格每一行头或者尾。 |
37 | 37 | ||
38 | 涓?瑕????杩?"format=flowed"????????琛???????????璧??????????????崇?????琛???? | 38 | 不要通过"format=flowed"模发补丁这会引不预以及害的行 |
39 | 39 | ||
40 | 涓?瑕?╀????????浠?㈡?风?????????????????????????浣????????? | 40 | 不你邮件客端进行自动这也破你补丁 |
41 | 41 | ||
42 | ???浠跺?㈡?风??涓???芥?瑰???????????瀛?绗????缂??????瑰?????瑕??????????琛ヤ???????芥??ASCII??????UTF-8缂??????瑰??锛? | 42 | 邮件客户端不能改变文本的字符集编码方式。要发送的补丁只能是ASCII或者UTF-8编码方式, |
43 | ????浣?浣??UTF-8?????????????????讹????d??浣????????浜??????????????????????棰???? | 43 | 如你UTF-8码送,那么你将会避免一些可发生的题。 |
44 | 44 | ||
45 | ???浠跺?㈡????ュ???骞?????? References: ?????? In-Reply-To: ????????? | 45 | 件客应形并且保 References: 或者 In-Reply-To: 那么 |
46 | ???浠惰??棰?灏?????????? | 46 | 邮件话就不中。 |
47 | 47 | ||
48 | 澶???剁??甯?(?????????璐寸??甯?)???甯镐????界?ㄤ??琛ヤ??锛????涓哄?惰〃绗?浼?杞????涓虹┖??笺??浣跨??xclipboard, xclip | 48 | 复制粘帖(或者剪贴粘帖)通常不能用于补丁,因为制表符会转换为空格。使用xclipboard, xclip |
49 | ??????xcutsel涔?璁稿??浠ワ??浣???????濂??璇??????????????ㄥ?????????? | 49 | 或者xcutsel也可,但一下或者免使复制粘帖。 |
50 | 50 | ||
51 | 涓?瑕???ㄤ娇???PGP/GPG缃插????????浠朵腑??????琛ヤ?????杩???蜂??浣垮??寰?澶???????涓???借?诲??????????ㄤ??浣????琛ヤ????? | 51 | 不要在使用PGP/GPG署名的邮件中包含补丁。这样会使得很多脚本不能读取和适用于你的补丁。 |
52 | ??涓????棰?搴?璇ユ?????浠慨澶????锛? | 52 | (这个题该可以修的) |
53 | 53 | ||
54 | ??ㄧ???????搁??浠跺??琛ㄥ?????琛ヤ??涔????锛?缁????宸卞?????涓?涓?琛ヤ?????涓?涓???????涓绘??锛?淇?瀛???ユ?跺?扮?? | 54 | 在给内核邮件列表发送补丁之前,给自己发送一个补丁是个不错的主意,保存接收到的 |
55 | ???浠???ヤ?????'patch'??戒????锛????????????锛????缁??????????琛???????? | 55 | 件,将补'patch'命上,如功了,再给内邮件列发送 |
56 | 56 | ||
57 | 57 | ||
58 | ?????浠跺??风?????? | 58 | 一些邮客提示 |
59 | ---------------------------------------------------------------------- | 59 | ---------------------------------------------------------------------- |
60 | 杩????缁???轰??浜?璇?缁????MUA???缃????绀猴?????浠ョ?ㄤ??缁?Linux?????稿?????琛ヤ?????杩?浜?骞朵???????虫?? | 60 | 这里给出一些详细的MUA配置提示,可以用于给Linux内核发送补丁。这些并不意味是 |
61 | ??????????跺????????????? | 61 | 件包置总结。 |
62 | 62 | ||
63 | 璇??锛? | 63 | 说: |
64 | TUI = ユ??????虹???????ㄦ???? | 64 | TUI = 以为础户口 |
65 | GUI = ??惧舰??????ㄦ???? | 65 | GUI = 图界户口 |
66 | 66 | ||
67 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 67 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
68 | Alpine (TUI) | 68 | Alpine (TUI) |
69 | 69 | ||
70 | ???????椤癸?? | 70 | 配选项 |
71 | ???"Sending Preferences"??ㄥ??? | 71 | 在"Sending Preferences"分: |
72 | 72 | ||
73 | - "Do Not Send Flowed Text"蹇?椤????? | 73 | - "Do Not Send Flowed Text"必须开 |
74 | - "Strip Whitespace Before Sending"蹇?椤诲?抽?? | 74 | - "Strip Whitespace Before Sending"必须关闭 |
75 | 75 | ||
76 | 褰????????讹?????????ユ?惧?ˉ?浼????扮?????????跺?????涓?CTRL-R?????????????? | 76 | 当写邮件,光应在补丁会现地,后CTRL-R合,使定 |
77 | 琛ヤ?????浠???????朵??? | 77 | 件到邮件中。 |
78 | 78 | ||
79 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 79 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
80 | Evolution (GUI) | 80 | Evolution (GUI) |
81 | 81 | ||
82 | 涓?浜?????????????????浣??????????? | 82 | 一些发成功使发送补丁 |
83 | 83 | ||
84 | 褰??????╅??浠??癸??Preformat | 84 | 选邮件选项:Preformat |
85 | 浠?Format->Heading->Preformatted (Ctrl-7)???????锋?? | 85 | 从Format->Heading->Preformatted (Ctrl-7)或者具栏 |
86 | 86 | ||
87 | ??跺??浣跨??? | 87 | 然后使: |
88 | Insert->Text File... (Alt-n x)?????ヨˉ????浠?? | 88 | Insert->Text File... (Alt-n x)入丁文件。 |
89 | 89 | ||
90 | 浣?杩?????"diff -Nru old.c new.c | xclip"???????Preformat锛???跺??浣跨?ㄤ腑??撮??杩??????? | 90 | 还可以"diff -Nru old.c new.c | xclip",择Preformat,使中间进行帖。 |
91 | 91 | ||
92 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 92 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
93 | Kmail (GUI) | 93 | Kmail (GUI) |
94 | 94 | ||
95 | ?浜?????????????????浣?????????琛????? | 95 | 一些开发者的使用发送丁 |
96 | 96 | ||
97 | 榛?よ?剧疆涓?涓?HTML??煎???????????????涓???????????? | 97 | 默认设不为HTML格式是合的不要启它 |
98 | 98 | ||
99 | 褰?涔????涓?灏????浠剁????跺??锛???ㄩ??椤逛?????涓?瑕??????╄????ㄦ?㈣????????涓????缂虹?瑰氨???浣???ㄩ??浠朵腑杈???ョ??浠讳???????? | 99 | 当书写一封邮件的时候,在选项下面不要选择自动换行。唯一的缺点就是你在邮件中输入的任何文本 |
100 | ??戒??浼?琚??????ㄦ?㈣??锛????姝や??蹇?椤诲?ㄥ?????琛ヤ??涔?????????ㄦ?㈣????????绠?????????规??灏辨???????ㄨ????ㄦ?㈣????ヤ功??????浠讹?? | 100 | 都不会被自动换行,因此你必须在发送补丁之前手动换行。最简单的方法就是启用自动换行来书写邮件, |
101 | ??跺?????瀹?淇?瀛?涓鸿??绋裤??涓????浣???ㄨ??绋夸腑???娆℃??寮?瀹?锛?瀹?宸茬????ㄩ?ㄨ????ㄦ?㈣??浜?锛???d??浣???????浠惰?界?舵病??? | 101 | 然后把它保存为草稿。一旦你在草稿中再次打开它,它已经全部自动换行了,那么你的邮件虽然没有 |
102 | ?????╄????ㄦ?㈣???????????????????????㈣????? | 102 | 自动行,但还不失去已的自 |
103 | 103 | ||
104 | ????浠??搴??????????ˉ?????锛?????哥?ㄧ??ヤ???????锛?涓?涓?杩?瀛????(---)??? | 104 | 在邮件部,入补丁之前,上补丁定:三个连号(---)。 |
105 | 105 | ||
106 | ??跺?????"Message"????????$??锛??????╂????ユ??浠讹????ョ????????浣????琛ヤ?????浠躲??杩????涓?涓?棰?澶???????椤癸??浣????浠? | 106 | 然后在"Message"菜单条目,选择插入文件,接着选取你的补丁文件。还有一个额外的选项,你可以 |
107 | ???杩?????缃?浣???????浠缓绔??????????锛?杩????ュ?"insert file"??????? | 107 | 它置邮件建工具菜单,还可以带上"insert file"图标 |
108 | 108 | ||
109 | 浣????浠ュ????ㄥ?伴??杩?GPG???璁伴??浠讹??浣???????宓?琛ヤ?????濂戒??瑕?浣跨??GPG???璁板??浠????浣?涓哄??宓??????????绛惧??琛ヤ??锛? | 109 | 你可以安全地通过GPG标记附件,但是内嵌补丁最好不要使用GPG标记它们。作为内嵌文本的签发补丁, |
110 | 褰?浠?GPG???????7浣?????????浣?????????????澶??????? | 110 | 当从GPG中取7位码会使他们的复。 |
111 | 111 | ||
112 | 濡????浣????瑕?浠ラ??浠剁??褰㈠????????琛ヤ??锛???d??灏卞?抽????瑰?婚??浠讹????跺?????涓?灞???э??绐????"Suggest automatic | 112 | 如果你非要以附件的形式发送补丁,那么就右键点击附件,然后选中属性,突出"Suggest automatic |
113 | display"锛??????????舵?村???璁╄?????????? | 113 | display",这件容读者看。 |
114 | 114 | ||
115 | 褰?浣?瑕?淇?瀛?灏?瑕?????????????宓???????琛ヤ??锛?浣????浠ヤ??娑???????琛ㄧ????奸????╁?????琛ヤ????????浠讹????跺????冲?婚????? | 115 | 当你要保存将要发送的内嵌文本补丁,你可以从消息列表窗格选择包含补丁的邮件,然后右击选择 |
116 | "save as"???浣????浠ヤ娇??ㄤ??涓?娌℃????存?圭????????琛ヤ????????浠讹??濡????瀹????浠ユ?g‘???褰㈠??缁???????褰?浣?姝g????ㄥ?? | 116 | "save as"。你可以使用一个没有更改的包含补丁的邮件,如果它是以正确的形式组成。当你正真在它 |
117 | ???宸辩??绐???d??涓?瀵????锛???f?舵病??????椤瑰??浠ヤ??瀛????浠?--宸茬?????涓?涓?杩???风??bug琚?姹???ュ?颁??kmail???bugzilla | 117 | 自己的窗口之下察看,那时没有选项可以保存邮件--已经有一个这样的bug被汇报到了kmail的bugzilla |
118 | 骞朵??甯????杩?灏?浼?琚?澶??????????浠舵??浠ュ?????瀵规??涓???ㄦ?峰??璇诲???????????琚?淇?瀛????锛????浠ュ?????浣???虫?????浠跺????跺?板?朵????版?癸?? | 118 | 并且希望这将会被处理。邮件是以只针对某个用户可读写的权限被保存的,所以如果你想把邮件复制到其他地方, |
119 | 浣?涓???????浠????????????负?????????翠?????璇?? | 119 | 你不不他们的改为者整体可读。 |
120 | 120 | ||
121 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 121 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
122 | Lotus Notes (GUI) | 122 | Lotus Notes (GUI) |
123 | 123 | ||
124 | 涓?瑕?浣?????? | 124 | 不使它 |
125 | 125 | ||
126 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 126 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
127 | Mutt (TUI) | 127 | Mutt (TUI) |
128 | 128 | ||
129 | ??Linux????浜??浣??mutt瀹㈡?风??锛????ヨ?????????瀹??????????????? | 129 | 多Linux人员使mutt客,以证明它工的非常漂亮。 |
130 | 130 | ||
131 | Mutt涓????甯?缂?杈????锛????浠ヤ??绠′??浣跨?ㄤ??涔?缂?杈???ㄩ?戒??搴?璇ュ甫????????ㄦ??琛????澶у????扮??杈???ㄩ?藉甫??? | 131 | Mutt不自带编辑器,所以不管你使用什么编辑器都不应该带有自动断行。大多数编辑器都带有 |
132 | 涓?涓?"insert file"???椤癸??????浠???????????跺??????瑰???????ユ??躲?? | 132 | 一个"insert file",可以通过不变内容入文件。 |
133 | 133 | ||
134 | 'vim'浣?涓?mutt????杈????锛? | 134 | 'vim'作为mutt辑器: |
135 | set editor="vi" | 135 | set editor="vi" |
136 | 136 | ||
137 | ????浣??xclip锛????ヤ涓???戒 | 137 | 如xclip,入下命 |
138 | :set paste | 138 | :set paste |
139 | ?????????????????shift-insert???????? | 139 | 中之前或者shift-insert使 |
140 | :r filename | 140 | :r filename |
141 | 141 | ||
142 | 濡???????????琛ヤ??????????????? | 142 | 要把补丁作为文本。 |
143 | (a)ttachヤ??????斤??涓?甯????"set paste"??? | 143 | (a)ttach作的很好,"set paste"。 |
144 | 144 | ||
145 | ???????椤癸?? | 145 | 配选项 |
146 | 瀹?搴?璇互榛?璁よ?疆???㈠??????? | 146 | 以默置的形式工作 |
147 | ????锛????"send_charset"剧疆涓?"us-ascii::utf-8"????涓?涓?涓???????涓????? | 147 | 然而,"send_charset"设为"us-ascii::utf-8"也一个不意。 |
148 | 148 | ||
149 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 149 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
150 | Pine (TUI) | 150 | Pine (TUI) |
151 | 151 | ||
152 | Pine杩?????????????????锛?浣????杩????板???璇???淇?澶?浜???? | 152 | Pine过一些格删减问题但这些现应被修了 |
153 | 153 | ||
154 | ???????浠ワ??璇???alpine(pine??????) | 154 | 如以,请使alpine(pine继承) |
155 | 155 | ||
156 | ???????椤癸?? | 156 | 配选项 |
157 | - ?????????????????娑???ゆ????????? | 157 | - 版本需要消除流文本 |
158 | - "no-strip-whitespace-before-send"?????????????????? | 158 | - "no-strip-whitespace-before-send"选项也要。 |
159 | 159 | ||
160 | 160 | ||
161 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 161 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
162 | Sylpheed (GUI) | 162 | Sylpheed (GUI) |
163 | 163 | ||
164 | - ?????????????ュ????ヤ??锛??????????浠讹????? | 164 | - 本可以很好作(使件)。 |
165 | - ???镐??????ㄧ???杈????? | 165 | - 许使用辑器 |
166 | - ????????????甯告????? | 166 | - 对于录非慢。 |
167 | - ???????杩?non-SSL???ワ?????娉???TLS SMTP????????? | 167 | - 如通non-SSL连,法使TLS SMTP授权。 |
168 | - ??ㄧ????????腑?????????????ruler bar??? | 168 | - 在组窗口中一个有用ruler bar。 |
169 | - ?????????娣诲??????灏??浼?g??????????? | 169 | - 地中就不会的显示名 |
170 | 170 | ||
171 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 171 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
172 | Thunderbird (GUI) | 172 | Thunderbird (GUI) |
173 | 173 | ||
174 | 榛?璁ゆ????典??锛?thunderbird寰?瀹规??????????????锛?浣????杩????涓?浜???规?????浠ュ己??跺?????寰???村ソ??? | 174 | 默认情况下,thunderbird很容易损坏文本,但是还有一些方法可以强制它变得更好。 |
175 | 175 | ||
176 | - ??ㄧ?ㄦ?????????????????????瑕???????"Compose messages in HTML format"??? | 176 | - 户号设成和寻,不"Compose messages in HTML format"。 |
177 | 177 | ||
178 | - ?杈?浣????Thunderbird????疆??娇瀹??瑕????琛?浣???user_pref("mailnews.wraplength", 0); | 178 | - 辑你的Thunderbird配设来使不要使:user_pref("mailnews.wraplength", 0); |
179 | 179 | ||
180 | - ?杈?浣????Thunderbird???缃?剧?浣垮??涓?瑕?浣??"format=flowed"??煎??锛?user_pref("mailnews. | 180 | - 辑你的Thunderbird配设置使不使用"format=flowed"格式:user_pref("mailnews. |
181 | send_plaintext_flowed", false); | 181 | send_plaintext_flowed", false); |
182 | 182 | ||
183 | - 浣????瑕?浣?Thunderbird??????????煎????瑰??锛? | 183 | - 你需要使Thunderbird变为预先式式: |
184 | 濡????榛?璁ゆ????典??浣?涔??????????HTML??煎??锛???d?????寰???俱??浠?浠?浠????棰???????涓????妗?涓???????"Preformat"??煎????? | 184 | 如果默认情况下你书写的是HTML格式,那不是很难。仅仅从标题栏的下拉框中选择"Preformat"格式。 |
185 | 濡????榛?璁ゆ????典??浣?涔??????????????????煎??锛?浣?涓?寰????瀹???逛负HTML??煎??锛?浠?浠?浣?涓轰??娆℃?х??锛???ヤ功?????扮??娑????锛? | 185 | 如果默认情况下你书写的是文本格式,你不得把它改为HTML格式(仅仅作为一次性的)来书写新的消息, |
186 | ??跺??寮哄?朵娇瀹??????版???????煎??锛???????瀹?灏变?????琛????瑕?瀹???板??锛???ㄥ??淇$????炬??涓?浣跨??shift?????ヤ娇瀹????涓?HTML | 186 | 然后强制使它回到文本格式,否则它就会拆行。要实现它,在写信的图标上使用shift键来使它变为HTML |
187 | ???????跺????????????????妗????????"Preformat"??煎????? | 187 | 格式,标的下中选择"Preformat"格式。 |
188 | 188 | ||
189 | - ???镐??????ㄧ???杈????锛? | 189 | - 许使用辑器: |
190 | ???瀵?Thunderbird???琛ヤ?????绠?????????规??灏辨??浣跨?ㄤ??涓?"external editor"??╁??锛???跺??浣跨?ㄤ????????娆㈢?? | 190 | 针对Thunderbird打补丁最简单的方法就是使用一个"external editor"扩展,然后使用你最喜欢的 |
191 | $EDITOR??ヨ?诲???????????骞惰ˉ涓???版?????涓????瑕?瀹???板??锛????浠ヤ??杞藉苟涓?瀹?瑁?杩?涓???╁??锛???跺??娣诲??涓?涓?浣跨?ㄥ????? | 191 | $EDITOR来读取或者合并补丁到文本中。要实现它,可以下载并且安装这个扩展,然后添加一个使用它的 |
192 | ??????View->Toolbars->Customize...??????褰??????淇???????跺???浠????诲??灏??浠????? | 192 | 按键View->Toolbars->Customize...后当你书写信候仅仅击它以了 |
193 | 193 | ||
194 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 194 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
195 | TkRat (GUI) | 195 | TkRat (GUI) |
196 | 196 | ||
197 | ???浠ヤ???????浣??"Insert file..."????????????杈????? | 197 | 以使它使"Insert file..."者外部辑器 |
198 | 198 | ||
199 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 199 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
200 | Gmail (Web GUI) | 200 | Gmail (Web GUI) |
201 | 201 | ||
202 | 涓??浣?????????琛????? | 202 | 不要使它送丁 |
203 | 203 | ||
204 | Gmail?椤??风???????ㄥ?版????〃?????┖??笺?? | 204 | Gmail客自动地转换空格。 |
205 | 205 | ||
206 | ??界?跺?惰〃绗?杞????涓虹┖??奸??棰????浠ヨ??澶???ㄧ??杈???ㄨВ??筹???????跺??杩?浼?浣跨?ㄥ??杞???㈣?????姣?琛???????涓?78涓?瀛?绗???? | 206 | 虽然制表符转换为空格问题可以被外部编辑器解决,同时它还会使用回车换行把每行拆分为78个字符。 |
207 | 207 | ||
208 | ???涓?涓????棰????Gmail杩?浼????浠讳??涓????ASCII???瀛?绗????淇℃????逛负base64缂???????瀹????涓?瑗垮????????娆ф床浜虹?????瀛???? | 208 | 另一个问题是Gmail还会把任何不是ASCII的字符的信息改为base64编码。它把东西变的像欧洲人的名字。 |
209 | 209 | ||
210 | ### | 210 | ### |
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index b605d01f5d45..21cf46f45245 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig | |||
@@ -16,6 +16,11 @@ config UEVENT_HELPER_PATH | |||
16 | that it creates a high system load, or on smaller systems | 16 | that it creates a high system load, or on smaller systems |
17 | it is known to create out-of-memory situations during bootup. | 17 | it is known to create out-of-memory situations during bootup. |
18 | 18 | ||
19 | To disable user space helper program execution at early boot | ||
20 | time specify an empty string here. This setting can be altered | ||
21 | via /proc/sys/kernel/hotplug or via /sys/kernel/uevent_helper | ||
22 | later at runtime. | ||
23 | |||
19 | config DEVTMPFS | 24 | config DEVTMPFS |
20 | bool "Maintain a devtmpfs filesystem to mount at /dev" | 25 | bool "Maintain a devtmpfs filesystem to mount at /dev" |
21 | depends on HOTPLUG | 26 | depends on HOTPLUG |
@@ -65,17 +70,17 @@ config PREVENT_FIRMWARE_BUILD | |||
65 | default y | 70 | default y |
66 | help | 71 | help |
67 | Say yes to avoid building firmware. Firmware is usually shipped | 72 | Say yes to avoid building firmware. Firmware is usually shipped |
68 | with the driver, and only when updating the firmware a rebuild | 73 | with the driver and only when updating the firmware should a |
69 | should be made. | 74 | rebuild be made. |
70 | If unsure say Y here. | 75 | If unsure, say Y here. |
71 | 76 | ||
72 | config FW_LOADER | 77 | config FW_LOADER |
73 | tristate "Userspace firmware loading support" if EXPERT | 78 | tristate "Userspace firmware loading support" if EXPERT |
74 | default y | 79 | default y |
75 | ---help--- | 80 | ---help--- |
76 | This option is provided for the case where no in-kernel-tree modules | 81 | This option is provided for the case where none of the in-tree modules |
77 | require userspace firmware loading support, but a module built outside | 82 | require userspace firmware loading support, but a module built |
78 | the kernel tree does. | 83 | out-of-tree does. |
79 | 84 | ||
80 | config FIRMWARE_IN_KERNEL | 85 | config FIRMWARE_IN_KERNEL |
81 | bool "Include in-kernel firmware blobs in kernel binary" | 86 | bool "Include in-kernel firmware blobs in kernel binary" |
@@ -83,22 +88,22 @@ config FIRMWARE_IN_KERNEL | |||
83 | default y | 88 | default y |
84 | help | 89 | help |
85 | The kernel source tree includes a number of firmware 'blobs' | 90 | The kernel source tree includes a number of firmware 'blobs' |
86 | which are used by various drivers. The recommended way to | 91 | that are used by various drivers. The recommended way to |
87 | use these is to run "make firmware_install" and to copy the | 92 | use these is to run "make firmware_install", which, after |
88 | resulting binary files created in usr/lib/firmware directory | 93 | converting ihex files to binary, copies all of the needed |
89 | of the kernel tree to the /lib/firmware on your system so | 94 | binary files in firmware/ to /lib/firmware/ on your system so |
90 | that they can be loaded by userspace helpers on request. | 95 | that they can be loaded by userspace helpers on request. |
91 | 96 | ||
92 | Enabling this option will build each required firmware blob | 97 | Enabling this option will build each required firmware blob |
93 | into the kernel directly, where request_firmware() will find | 98 | into the kernel directly, where request_firmware() will find |
94 | them without having to call out to userspace. This may be | 99 | them without having to call out to userspace. This may be |
95 | useful if your root file system requires a device which uses | 100 | useful if your root file system requires a device that uses |
96 | such firmware, and do not wish to use an initrd. | 101 | such firmware and do not wish to use an initrd. |
97 | 102 | ||
98 | This single option controls the inclusion of firmware for | 103 | This single option controls the inclusion of firmware for |
99 | every driver which uses request_firmware() and ships its | 104 | every driver that uses request_firmware() and ships its |
100 | firmware in the kernel source tree, to avoid a proliferation | 105 | firmware in the kernel source tree, which avoids a |
101 | of 'Include firmware for xxx device' options. | 106 | proliferation of 'Include firmware for xxx device' options. |
102 | 107 | ||
103 | Say 'N' and let firmware be loaded from userspace. | 108 | Say 'N' and let firmware be loaded from userspace. |
104 | 109 | ||
@@ -106,27 +111,27 @@ config EXTRA_FIRMWARE | |||
106 | string "External firmware blobs to build into the kernel binary" | 111 | string "External firmware blobs to build into the kernel binary" |
107 | depends on FW_LOADER | 112 | depends on FW_LOADER |
108 | help | 113 | help |
109 | This option allows firmware to be built into the kernel, for the | 114 | This option allows firmware to be built into the kernel for the case |
110 | cases where the user either cannot or doesn't want to provide it from | 115 | where the user either cannot or doesn't want to provide it from |
111 | userspace at runtime (for example, when the firmware in question is | 116 | userspace at runtime (for example, when the firmware in question is |
112 | required for accessing the boot device, and the user doesn't want to | 117 | required for accessing the boot device, and the user doesn't want to |
113 | use an initrd). | 118 | use an initrd). |
114 | 119 | ||
115 | This option is a string, and takes the (space-separated) names of the | 120 | This option is a string and takes the (space-separated) names of the |
116 | firmware files -- the same names which appear in MODULE_FIRMWARE() | 121 | firmware files -- the same names that appear in MODULE_FIRMWARE() |
117 | and request_firmware() in the source. These files should exist under | 122 | and request_firmware() in the source. These files should exist under |
118 | the directory specified by the EXTRA_FIRMWARE_DIR option, which is | 123 | the directory specified by the EXTRA_FIRMWARE_DIR option, which is |
119 | by default the firmware/ subdirectory of the kernel source tree. | 124 | by default the firmware subdirectory of the kernel source tree. |
120 | 125 | ||
121 | So, for example, you might set CONFIG_EXTRA_FIRMWARE="usb8388.bin", | 126 | For example, you might set CONFIG_EXTRA_FIRMWARE="usb8388.bin", copy |
122 | copy the usb8388.bin file into the firmware/ directory, and build the | 127 | the usb8388.bin file into the firmware directory, and build the kernel. |
123 | kernel. Then any request_firmware("usb8388.bin") will be | 128 | Then any request_firmware("usb8388.bin") will be satisfied internally |
124 | satisfied internally without needing to call out to userspace. | 129 | without needing to call out to userspace. |
125 | 130 | ||
126 | WARNING: If you include additional firmware files into your binary | 131 | WARNING: If you include additional firmware files into your binary |
127 | kernel image which are not available under the terms of the GPL, | 132 | kernel image that are not available under the terms of the GPL, |
128 | then it may be a violation of the GPL to distribute the resulting | 133 | then it may be a violation of the GPL to distribute the resulting |
129 | image -- since it combines both GPL and non-GPL work. You should | 134 | image since it combines both GPL and non-GPL work. You should |
130 | consult a lawyer of your own before distributing such an image. | 135 | consult a lawyer of your own before distributing such an image. |
131 | 136 | ||
132 | config EXTRA_FIRMWARE_DIR | 137 | config EXTRA_FIRMWARE_DIR |
@@ -136,10 +141,9 @@ config EXTRA_FIRMWARE_DIR | |||
136 | help | 141 | help |
137 | This option controls the directory in which the kernel build system | 142 | This option controls the directory in which the kernel build system |
138 | looks for the firmware files listed in the EXTRA_FIRMWARE option. | 143 | looks for the firmware files listed in the EXTRA_FIRMWARE option. |
139 | The default is the firmware/ directory in the kernel source tree, | 144 | The default is firmware/ in the kernel source tree, but by changing |
140 | but by changing this option you can point it elsewhere, such as | 145 | this option you can point it elsewhere, such as /lib/firmware/ or |
141 | the /lib/firmware/ directory or another separate directory | 146 | some other directory containing the firmware files. |
142 | containing firmware files. | ||
143 | 147 | ||
144 | config DEBUG_DRIVER | 148 | config DEBUG_DRIVER |
145 | bool "Driver Core verbose debug messages" | 149 | bool "Driver Core verbose debug messages" |
diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c index fa7f0b3e81dd..68810fd1a59d 100644 --- a/drivers/firmware/google/gsmi.c +++ b/drivers/firmware/google/gsmi.c | |||
@@ -869,8 +869,6 @@ static __init int gsmi_init(void) | |||
869 | goto out_err; | 869 | goto out_err; |
870 | } | 870 | } |
871 | 871 | ||
872 | printk(KERN_INFO "gsmi version " DRIVER_VERSION " loaded\n"); | ||
873 | |||
874 | /* Register in the firmware directory */ | 872 | /* Register in the firmware directory */ |
875 | ret = -ENOMEM; | 873 | ret = -ENOMEM; |
876 | gsmi_kobj = kobject_create_and_add("gsmi", firmware_kobj); | 874 | gsmi_kobj = kobject_create_and_add("gsmi", firmware_kobj); |
@@ -890,12 +888,13 @@ static __init int gsmi_init(void) | |||
890 | ret = sysfs_create_files(gsmi_kobj, gsmi_attrs); | 888 | ret = sysfs_create_files(gsmi_kobj, gsmi_attrs); |
891 | if (ret) { | 889 | if (ret) { |
892 | printk(KERN_INFO "gsmi: Failed to add attrs"); | 890 | printk(KERN_INFO "gsmi: Failed to add attrs"); |
893 | goto out_err; | 891 | goto out_remove_bin_file; |
894 | } | 892 | } |
895 | 893 | ||
896 | if (register_efivars(&efivars, &efivar_ops, gsmi_kobj)) { | 894 | ret = register_efivars(&efivars, &efivar_ops, gsmi_kobj); |
895 | if (ret) { | ||
897 | printk(KERN_INFO "gsmi: Failed to register efivars\n"); | 896 | printk(KERN_INFO "gsmi: Failed to register efivars\n"); |
898 | goto out_err; | 897 | goto out_remove_sysfs_files; |
899 | } | 898 | } |
900 | 899 | ||
901 | register_reboot_notifier(&gsmi_reboot_notifier); | 900 | register_reboot_notifier(&gsmi_reboot_notifier); |
@@ -903,9 +902,15 @@ static __init int gsmi_init(void) | |||
903 | atomic_notifier_chain_register(&panic_notifier_list, | 902 | atomic_notifier_chain_register(&panic_notifier_list, |
904 | &gsmi_panic_notifier); | 903 | &gsmi_panic_notifier); |
905 | 904 | ||
905 | printk(KERN_INFO "gsmi version " DRIVER_VERSION " loaded\n"); | ||
906 | |||
906 | return 0; | 907 | return 0; |
907 | 908 | ||
908 | out_err: | 909 | out_remove_sysfs_files: |
910 | sysfs_remove_files(gsmi_kobj, gsmi_attrs); | ||
911 | out_remove_bin_file: | ||
912 | sysfs_remove_bin_file(gsmi_kobj, &eventlog_bin_attr); | ||
913 | out_err: | ||
909 | kobject_put(gsmi_kobj); | 914 | kobject_put(gsmi_kobj); |
910 | gsmi_buf_free(gsmi_dev.param_buf); | 915 | gsmi_buf_free(gsmi_dev.param_buf); |
911 | gsmi_buf_free(gsmi_dev.data_buf); | 916 | gsmi_buf_free(gsmi_dev.data_buf); |
@@ -925,6 +930,8 @@ static void __exit gsmi_exit(void) | |||
925 | &gsmi_panic_notifier); | 930 | &gsmi_panic_notifier); |
926 | unregister_efivars(&efivars); | 931 | unregister_efivars(&efivars); |
927 | 932 | ||
933 | sysfs_remove_files(gsmi_kobj, gsmi_attrs); | ||
934 | sysfs_remove_bin_file(gsmi_kobj, &eventlog_bin_attr); | ||
928 | kobject_put(gsmi_kobj); | 935 | kobject_put(gsmi_kobj); |
929 | gsmi_buf_free(gsmi_dev.param_buf); | 936 | gsmi_buf_free(gsmi_dev.param_buf); |
930 | gsmi_buf_free(gsmi_dev.data_buf); | 937 | gsmi_buf_free(gsmi_dev.data_buf); |
diff --git a/drivers/misc/pti.c b/drivers/misc/pti.c index 374dfcfccd07..e5f295a38a34 100644 --- a/drivers/misc/pti.c +++ b/drivers/misc/pti.c | |||
@@ -445,9 +445,9 @@ static void pti_tty_driver_close(struct tty_struct *tty, struct file *filp) | |||
445 | } | 445 | } |
446 | 446 | ||
447 | /** | 447 | /** |
448 | * pti_tty_intstall()- Used to set up specific master-channels | 448 | * pti_tty_install()- Used to set up specific master-channels |
449 | * to tty ports for organizational purposes when | 449 | * to tty ports for organizational purposes when |
450 | * tracing viewed from debuging tools. | 450 | * tracing viewed from debuging tools. |
451 | * | 451 | * |
452 | * @driver: tty driver information. | 452 | * @driver: tty driver information. |
453 | * @tty: tty struct containing pti information. | 453 | * @tty: tty struct containing pti information. |
diff --git a/drivers/uio/uio_pdrv_genirq.c b/drivers/uio/uio_pdrv_genirq.c index 31e799d9efe5..bae96d246760 100644 --- a/drivers/uio/uio_pdrv_genirq.c +++ b/drivers/uio/uio_pdrv_genirq.c | |||
@@ -23,6 +23,10 @@ | |||
23 | #include <linux/pm_runtime.h> | 23 | #include <linux/pm_runtime.h> |
24 | #include <linux/slab.h> | 24 | #include <linux/slab.h> |
25 | 25 | ||
26 | #include <linux/of.h> | ||
27 | #include <linux/of_platform.h> | ||
28 | #include <linux/of_address.h> | ||
29 | |||
26 | #define DRIVER_NAME "uio_pdrv_genirq" | 30 | #define DRIVER_NAME "uio_pdrv_genirq" |
27 | 31 | ||
28 | struct uio_pdrv_genirq_platdata { | 32 | struct uio_pdrv_genirq_platdata { |
@@ -97,6 +101,27 @@ static int uio_pdrv_genirq_probe(struct platform_device *pdev) | |||
97 | int ret = -EINVAL; | 101 | int ret = -EINVAL; |
98 | int i; | 102 | int i; |
99 | 103 | ||
104 | if (!uioinfo) { | ||
105 | int irq; | ||
106 | |||
107 | /* alloc uioinfo for one device */ | ||
108 | uioinfo = kzalloc(sizeof(*uioinfo), GFP_KERNEL); | ||
109 | if (!uioinfo) { | ||
110 | ret = -ENOMEM; | ||
111 | dev_err(&pdev->dev, "unable to kmalloc\n"); | ||
112 | goto bad2; | ||
113 | } | ||
114 | uioinfo->name = pdev->dev.of_node->name; | ||
115 | uioinfo->version = "devicetree"; | ||
116 | |||
117 | /* Multiple IRQs are not supported */ | ||
118 | irq = platform_get_irq(pdev, 0); | ||
119 | if (irq == -ENXIO) | ||
120 | uioinfo->irq = UIO_IRQ_NONE; | ||
121 | else | ||
122 | uioinfo->irq = irq; | ||
123 | } | ||
124 | |||
100 | if (!uioinfo || !uioinfo->name || !uioinfo->version) { | 125 | if (!uioinfo || !uioinfo->name || !uioinfo->version) { |
101 | dev_err(&pdev->dev, "missing platform_data\n"); | 126 | dev_err(&pdev->dev, "missing platform_data\n"); |
102 | goto bad0; | 127 | goto bad0; |
@@ -180,6 +205,10 @@ static int uio_pdrv_genirq_probe(struct platform_device *pdev) | |||
180 | kfree(priv); | 205 | kfree(priv); |
181 | pm_runtime_disable(&pdev->dev); | 206 | pm_runtime_disable(&pdev->dev); |
182 | bad0: | 207 | bad0: |
208 | /* kfree uioinfo for OF */ | ||
209 | if (pdev->dev.of_node) | ||
210 | kfree(uioinfo); | ||
211 | bad2: | ||
183 | return ret; | 212 | return ret; |
184 | } | 213 | } |
185 | 214 | ||
@@ -193,6 +222,10 @@ static int uio_pdrv_genirq_remove(struct platform_device *pdev) | |||
193 | priv->uioinfo->handler = NULL; | 222 | priv->uioinfo->handler = NULL; |
194 | priv->uioinfo->irqcontrol = NULL; | 223 | priv->uioinfo->irqcontrol = NULL; |
195 | 224 | ||
225 | /* kfree uioinfo for OF */ | ||
226 | if (pdev->dev.of_node) | ||
227 | kfree(priv->uioinfo); | ||
228 | |||
196 | kfree(priv); | 229 | kfree(priv); |
197 | return 0; | 230 | return 0; |
198 | } | 231 | } |
@@ -219,6 +252,15 @@ static const struct dev_pm_ops uio_pdrv_genirq_dev_pm_ops = { | |||
219 | .runtime_resume = uio_pdrv_genirq_runtime_nop, | 252 | .runtime_resume = uio_pdrv_genirq_runtime_nop, |
220 | }; | 253 | }; |
221 | 254 | ||
255 | #ifdef CONFIG_OF | ||
256 | static const struct of_device_id __devinitconst uio_of_genirq_match[] = { | ||
257 | { /* empty for now */ }, | ||
258 | }; | ||
259 | MODULE_DEVICE_TABLE(of, uio_of_genirq_match); | ||
260 | #else | ||
261 | # define uio_of_genirq_match NULL | ||
262 | #endif | ||
263 | |||
222 | static struct platform_driver uio_pdrv_genirq = { | 264 | static struct platform_driver uio_pdrv_genirq = { |
223 | .probe = uio_pdrv_genirq_probe, | 265 | .probe = uio_pdrv_genirq_probe, |
224 | .remove = uio_pdrv_genirq_remove, | 266 | .remove = uio_pdrv_genirq_remove, |
@@ -226,6 +268,7 @@ static struct platform_driver uio_pdrv_genirq = { | |||
226 | .name = DRIVER_NAME, | 268 | .name = DRIVER_NAME, |
227 | .owner = THIS_MODULE, | 269 | .owner = THIS_MODULE, |
228 | .pm = &uio_pdrv_genirq_dev_pm_ops, | 270 | .pm = &uio_pdrv_genirq_dev_pm_ops, |
271 | .of_match_table = uio_of_genirq_match, | ||
229 | }, | 272 | }, |
230 | }; | 273 | }; |
231 | 274 | ||