最初の試みは成功しない可能性があります。そのような結果の可能性を減らすための推奨事項を以下に示します。 変更の準備および送信中の問題の主な領域について簡単に説明します。
- 廃止された保守的な特別なカーネルサブシステム
- コードスタイルとデザインの変更
- 変更の新規性
- プロセスのニュアンス
さらに、既存の検証メカニズムについて簡単に説明します。
カーネルサブシステム
カーネルサブシステムの全セットの中で、以下を区別します。
- arch / <アーキテクチャ>
- ドライバー/ scsi
- fs /（主要部分）
- ドライバー/ isdn、drivers / ideなど
- ドライバー/ステージング
1つはアーキテクチャコードです。 多くの場合、慎重な調査と理解を必要とするレガシーアーキテクチャまたはコードが含まれています。 そこにあるものを変更することは、テストできる鉄片と、実際に苦労している実際の問題がある場合にのみ意味があります。
2番目のSCSIは、おそらくカーネル内で最も保守的なサブシステムですが、変更をそこにドラッグすることもできますが、これは最も難しい方法です。
3番目は、ファイルシステムサポートの大部分です。 コアの非常に具体的で敏感なサブシステムの1つ。 Al Viroのメンテナーは一言も言いません。あなたが考えずに何かをしようとしても、気分を害することはありません。楽しい答えは得られません。
4番目のカテゴリは廃止されたサブシステムであるため、内部APIを変更する場合、グローバル編集のみが受け入れられます。
5つ目のサブシステム！ 先ほどステージングについて言及したことは何もありません。 このサブシステムでは、ドライバーはインキュベーション期間を通過します。つまり、一方ではドライバーの必要性が市場によって引き起こされます（デバイスがあり、サポートが必要です）が、他方では、コードの品質が既存のサブシステムの1つに含まれるのに十分ではありません。 ペンをサンプリングするのに最適な場所です。 Greg KHは非常に忠実なメンテナーです。送信する前に変更を確認するだけで、そうでなければ動揺します。
スタイルとデザイン
コードのスタイルと変更の設計に関するドキュメントには、 CodingStyleとSubmittingPatchesという非常に優れた資料があります。 アクションを開始する前に、それらに精通することを強くお勧めします。
変更の新規性
変更を行う前に、見て、誰かがすでに同じことをしているのではないか？ 作品を複製しても意味がありません。 そのため、たとえば、ユーザーblueboar2が変更を行いましたが、ほぼ1年前に以前のバージョンがあることが判明しました。 そしてよく見ると、 もっと古いものを見つけることができます。
プロセスのニュアンス
変更に対する反応がない場合は、元気づけてください。
最初に、鉱夫が忙しいか休んでいる可能性があることに注意してください。
第二に、公衆の変化の通常の露出時間は1週間以上です。 このようにして、メンテナーはコミュニティの他のメンバーが提案された変更について発言できるようにします。
第三に、四半期ごとに約2週間の沈黙があります。 これは、いわゆるマージウィンドウ、つまりサブシステムのメンテナーが前のサイクルで蓄積された変更をメインのサイクル、つまりLinusに送信するときのウィンドウです。 このウィンドウは、近い将来のv4.0で次の安定バージョンがリリースされた瞬間から始まります。 また、多くのメンテナーは-rc5の後に新しいコードの受け入れを停止することを考慮する必要があります（v4.0-rc5は3月23日月曜日に予定されています）。
検証メカニズム
以下に、変更をチェックするためのいくつかの方法とツールについて説明します。
最初に、変更が少なくともコンパイルされていることを確認します。 たとえば、ドライバー/ステージング/unisys/virtpci/virtpci.cを編集した場合、drivers / staging / unisys / virtpci / Makefileを使用して、ドライバーを有効にする責任がある構成オプションを簡単に理解できます。
obj-$(CONFIG_UNISYS_VIRTPCI) += virtpci.o
つまり、このオプションを有効にする方法を見つける必要があります。 編集はステージング、unisysサブディレクトリ、UNISYSPARメニューが定義されているKconfigで行われることがわかっているため、一度に複数のオプションを有効にする必要があります。
CONFIG_STAGING = y
CONFIG_UNISYSPAR = y
CONFIG_UNISYS_VIRTPCI = m
make menuconfig
のパスを
make menuconfig
、説明から含めるものを推測することもできます。
場合によっては、アセンブリが別のアーキテクチャで実行される場合、仮想マシン（KVM / Qemu）で実行するか、（まれな場合）KconfigでCOMPILE_TESTに依存関係を追加することができます。
--- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -269,7 +269,7 @@ config ATA_PIIX config SATA_DWC tristate "DesignWare Cores SATA support" - depends on 460EX + depends on 460EX || COMPILE_TEST help This option enables support for the on-chip SATA controller of the AppliedMicro processor 460EX.
そして、カーネル構成に追加します。
CONFIG_COMPILE_TEST = y
これらのパッチがすべてのアーキテクチャで収集され、大量の警告が出されないことを確認せずに、このようなパッチを送信することは絶対にありません。
アセンブリをテストする方法は？ ここで、アセンブリ中に次のすばらしい環境変数、つまり
W=1 C=1
進み
W=1 C=1
。 1つ目はコンパイラの警告レベルを上げ、2つ目は
sparse
パッケージがインストールされると静的コードアナライザーを起動します。 したがって、
-j8
と組み合わせると、次のようになります。
$ make C=1 W=1 -j8
ビルドする前に、実行すると便利です：
$ make includecheck
同じ* .hファイルの重複する包含を検索します。
これで、組み立てられたモジュールが手に入ります。
git format-patch
を使用して、変更を* .patchファイルとしてフォーマットしました。 コードのスタイルを確認するといいでしょう。
checkpatch.pl
実行します。
$ scripts/checkpatch.pl 00* total: 0 errors, 0 warnings, 43 lines checked 0001-dmaengine-hsu-remove-redundant-pieces-of-code.patch has no obvious style problems and is ready for submission.
もう一度、送信する前に、すべてが設計どおりになっていることを確認してください。
git send-email
大胆に実行し
git send-email
。
最後に、最も簡単な変更のために、trivial @ kernel.orgという特別なアドレスがあります。 Howto ： Submitting（Trivial）Linux Kernel Patchesのような別の記事を読んでください。