よって翻訳されました。カーネルと緊密に連携することで、カーネルの断片化を軽減します。ソースで維持されます。第一の選択肢として使用して、コード変更をアップストリームに送信する必要があります。android-mainlineブランチに送信する必要があります。正当な理由の例とその対処方法は次のとおりです。提出されましたが、製品リリースまでに受け入れられませんでした。送信されたという証拠と、パッチに対して受け取ったコメント、またはパッチがアップストリームに送信されるまでの推定時間を提供します。削除するという一連の行動を決定します。モジュールのEXPORT_SYMBOLS_GPL()を定義していますが、そのシンボルを使用するツリー内モジュールがないため、アップストリームに送信できませんでした。このパッチを処理するには、モジュールをアップストリームに送信できない理由と、このリクエストを行う前に検討した代替案の詳細を提供してください。このパッチはアップストリーム向けに十分汎用的ではないため、製品リリース前にリファクタリングする時間がありません。受け入れられません)。このパッチはアップストリームによって受け入れられません。チームに連絡し、レビューのために提出してアップストリームで受け入れられるように、パッチをリファクタリングするオプションについて協力してください。正当化できる可能性は他にもたくさんあります。バグやパッチを送信するときは、有効な理由を含めて、反復と議論を期待してください。いくつかのパッチが含まれることを認識しています。アップストリームの要件は時間の経過とともにさらに厳しくなることが予想されます。カーネルのコーディング標準に準拠する必要があります。事前送信テストの一部として実行されるため、事前に実行して、合格することを確認してください。スクリプトを実行するには、リポジトリのチェックアウトからbuild/static_analysis/checkpatch_presubmit.shを使用します。ガイドラインに準拠する必要があります。メッセージにはChange-Idタグを含める必要があります。送信する場合は、パッチのすべてのインスタンスに同じChange-Idを使用する必要があります。パッチが次の場合:アップストリームで受け入れられ、自動的にandroid-mainlineにマージされます。アップストリームで受け入れられませんでした。android-mainlineに送信してください。バックポートできます。パッチが含まれることが保証されます。(パッチはすでにandroid-mainlineにある可能性が高いため)。(受け入れられる可能性の高い順にリストされています)。受け入れられる可能性があります。適切な使用例があれば、アップストリームからのパッチが適切に選択されず、修正が必要な場合も受け入れられる可能性があります。ブランチから厳選されたパッチは、期限が迫っている場合には受け入れられる可能性があります。これらは内容とスケジュールの両方で正当化される必要があります。(私たちはそう想定しています)そうはならないだろう)。FROMLISTパッチに関連する問題が必要です。送信してみることができます。(例については、前のリストを参照してください)。コードを上流に送信できない場合がいくつかあります。固有のパッチの貢献ガイドラインに従い、件名にANDROID:プレフィックスを付けてタグ付けする必要があります。バージョンの両方に適用する必要があります。内で問題を作成し、変更について話し合ってください。フリーズされた後に影響を与えるCONFIG変更はすべて拒否されます。つの構成に対して競合する設定を要求した場合、関連するバグについての議論を通じて競合を解決します。固有になっているコードへの変更をアップストリームに送信することはできません。固有であるため、アップストリームに送信できません。コードをアップストリームに送信できない理由をバグとパッチで明確にしてください。維持されるツリー外のコードの量を最小限に抑えます。スクリプトまたは構成、またはアップストリームに存在しないその他のスクリプトの更新があります。ツリー外のモジュールの構築のサポートを積極的に阻止しています。メンテナがカーネル内のソースやバイナリの互換性を保証しておらず、ツリーにないコードをサポートしたくないことを考えると、これは合理的な立場です。インターフェイスが安定していることを保証します。モジュールをサポートするための変更のクラスが存在します。ツリーにない場合にEXPORT_SYMBOL_GPL()マクロを追加するパッチを考えてみましょう。モジュールをアップストリームできない理由を問題に含める必要があります。バリアントであるEXPORT_SYMBOL()リクエストしないでください。gki_defconfigで指定できない非表示の構成を自動的に選択します。CONFIG_SND_SOC_TOPOLOGYが自動的に選択されます。非表示の構成を有効にするメカニズムが含まれています。init/Kconfig.gkiにselectステートメントを追加します。gki_defconfigで有効になっているCONFIG_GKI_HACKS_TO_FIXカーネル構成に基づいて自動的に選択されます。このメカニズムは、非表示の構成にのみ使用してください。gki_defconfigで明示的に、または依存関係として指定する必要があります。オーバーライドできます。チームに相談してください。私たちはあなたと上流のメンテナーと協力して、必要なサポートを追加します。カーネルに直接追加できました。受け入れられないからです。フックを受け入れます。フィールドを主要なデータ構造に埋め込むことができます。モジュールが処理のために接続できるフックをdo_exit()に追加できます。フックが含まれています。nameのトレースポイント関数を作成します。nameトレースの一意の識別子です。sched_exit()フックの名前はandroid_vh_sched_exitになります。フックなどの場合に必要です。フックはデタッチできないため、制限されたフックにアタッチされたモジュールはアンロードできません。あるため、他の添付試行は-EBUSYで失敗します。フック名はandroid_rvhで始まります。固有のすべてのパッチと同様、問題が存在する必要があり、その理由を提供する必要があります)。送信しないでください。データを主要なデータ構造に関連付けることができます。サンプルに示すように構造体にフィールドを追加します。ANDROID_VENDOR_DATA()マクロを使用して宣言されたフィールドを決して使用してはなりません。ANDROID_OEM_DATA()を使用してandroid_oem_dataフィールドを宣言する必要があります。DECLARE_HOOK()またはDECLARE_RESTRICTED_HOOK()を使用して宣言し、トレースポイントとしてコードに追加します。trace_android_vh_sched_exit()既存のdo_exit()カーネル関数に追加するには、次のようにします。...}trace_android_vh_sched_exit()関数は、最初に何かが接続されているかどうかのみをチェックします。モジュールがregister_trace_android_vh_sched_exit()を使用してハンドラーを登録すると、登録された関数が呼び出されます。状態、およびその他の要素に関するコンテキストを認識している必要があります。ファイルで定義する必要があります。次のコードは、ファイルinclude/trace/hooks/exit.h内のtrace_android_vh_sched_exit()の可能な宣言を示します。ファイルをdrivers/android/vendor_hooks.cに追加し、シンボルをエクスポートします。次のコードはandroid_vh_sched_exit()フックの宣言を完了します。安定性を保証するには、フック宣言内で使用されるデータ構造を完全に定義する必要があります。しないと、不透明なポインターを逆参照したり、サイズ指定されたコンテキストで構造体を使用したりするのは安全ではありません。__GENKSYMS__セクション内に含める必要があります。ファイルを含めないでください。代わりに型を前方宣言します。(通常はモジュールの初期化中に行われます)。trace_android_vh_sched_exit()のモジュールfoo.koハンドラーを示しています。カーネルに追加する必要があります。問題を作成して、会話を開始します。ファイルへの変更はアップストリームで行う必要があります。ユーザー空間コード間のインターフェイスを定義します。モジュールでのみ有効です)。ノードでない場合はアップストリームで変更する必要があります。ノードを作成できます。ノードへのアクセスは拒否されます。ラベルを追加するかどうかは、ベンダーの責任です。ノードをデバッグします。debugfsはデバイスの通常の動作中にマウントされないため)。ライセンスに記載のライセンスに従います。関連会社の商標または登録商標です。