Linuxカーネルソースを使用する場合の* _defconfigの変更の何が問題になっていますか

私の最初の出版物の痕跡に続いて、Linuxカーネルソースパッケージに含まれるi386_defconfigまたはx86_64_defconfigファイルの変更に関する小さなメモを作成したいと思います。







その出版物へのコメントでは、ユーザー（特にValdikSS ）が興味を持っていました。なぜ.configを編集しませんか？ コメントの規模については、そこで詳細な回答をすることはできませんでした。



それでは、.configと* _defconfigの違いから始めましょう。 丁寧なユーザーがチームを入力

wc -l .config arch/x86/configs/{i386,x86_64}_defconfig
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルの違いが約10（！）回であることを簡単に検出できます。



make *_defconfig



は何をしますか？ 実際、特別なことは何もありません。 重要なアクションは以下のとおりです。

• 現在のカーネルバージョンで古くなっている、または欠落しているオプションを削除します。
• オプションの依存関係ツリーを構築します
• デフォルトの構成および依存関係で指定されたすべてのオプションにデフォルトのルールを適用します
• これらすべてを.configファイルに変換します

したがって、ファイルの単なるコピーではありません。



元のバージョン* _defconfigの編集に戻ります。 利点は何ですか？

• 必要な最小限の変更、残りはスクリプトによって行われます
• 安定したベース（ git diff
  
  
  
  ）との違いを常に見ることができます

欠点？

• まれにgit bisect
  
  
  
  を実行するのは不便です
• あなた自身の地元のブランチが必要です（これは利点と欠点の両方になる可能性があります）

リストの中で、Gitでファイルを編集する標準的なプラクティスには、独自のブランチの作成が含まれることを既に示唆しています。 そこで、独自の変更を蓄積します。 私にとっては、長所が短所を上回っていたため、* _defconfigの編集で非難されるものは見当たりません。



あなたの慣習は何ですか？