昨日、[ポエム]Linuxカーネルに関する独自コードをメンテナンスに関してという物を書きました。
本記事では、メインライン化の大変さを述べます。次にフォークコスト高すぎ問題について述べます。
先の記事については3行で書くと…
- Linux（カーネル）といえども、特別なことはなくソフトウェアなので変更をしたくなることがある。機能の追加やバグ修正といったもので一般的なオープンソースソフトウェアと同じである。
- 作ったソースコード（パッチ）をメインライン化（コミュニティに取り込んでもらってマージしてもらうこと）を基本とするべきであることを経験的に知っている。
- しかしながら、諸般の事情でメインライン化できないこともあるだろう。大事なことはメインライン化したときのメリット・デメリットは検討することではないだろうか。
みたいな感じです。（雑）
2018年にセルフツッコミを書きたくなってしまう人です。ポエムっぽい。
メインライン化は簡単ではないとは？
まず、メインライン化とは何かという点をクリアにしておきます。ここでは自分が作ったパッチをコミュニティに送って最終的には取り込んでもらうことを指すことにします。
メインライン化の頓挫と表現した場合は、パッチが取り込んでもらえなかった状況を想像していただければと思います。
話を分かりやすくするため、シナリオ形式で書いてみたいと思います。
シチュエーション
・・・ここに会社に雇われているプログラマーがいます。名前は勇者といいます。
この会社では現在とある製品の後継機種を設計しており、ハードウェアエンジニアはコスト削減のために部品の一部を変更することにしました。
変更された部品はソフトウェアから制御する必要があるものであるため、ソフトウェアの変更が必要か確認されました。
確認の結果、新しく採用された部品（デバイス）を動作させるために必要なデバイスドライバーが残念ながらLinuxでは提供されていないことが分かりました。
あなたはハードウェアと仕様書を渡され、Linuxで動くようにしてほしいと仕事を依頼されました。
無事にやり遂げ、開発完了したソースコードは1000行程度の簡単なもので収まり、社内の品質テストにも合格しています。
git diff -urn とすることでパッチ形式で出力できる状態です。
・・・
シナリオ1 メインライン化に理解がない。社内的な仕組み・ルールがない。
勇者はメインライン化の必要性があると感じたため、上司に少し工数がもう少し欲しいと相談しました。No1. 上司「メインライン化って何？」-> 勇者は説明を始めた。
--> でも、上司はピンときておらず困惑している！ -> もういいや。
No2. 上司個人にはメインライン化の理解はあるが、会社としての見解がない場合等
「でも、会社の成果物を勝手に出すのは法務部とかに確認が必要そうだなぁ…」 -> もういいや。
「でも、工数は開発と品質テストの分しか確保してないからできないよ。」 -> 勇者は次のプロジェクトへ…
「好きにやったら良いと思うよ、責任は取れないけど。」 -> もういいや。
社内にルールや前例がないと往々にして動けないことがあります。これは正しいことなのですが話が急に大事になってしまい頓挫する例です。
このような場合エンジニアはメンテナンスコストとメインライン化の作業についてPros/Consをとって取りまとめておき、責任者に承認を得るのがベターだと思われます。（つまり、現場レベルでは少なくとも責務を果たしているという状態にしておく）
ただし、メインライン化とはなんぞや？から始まる場合はPros/Consシートの価値を理解することができない環境ということになるのでつらいですね。解は仲間を頑張って見つけて機運を高めるように頑張ってみる、上司を説得して業務課題化する、俺が上司だ！、理解ある会社に転職してしまうなどがあります。
ちなみに、ここでは勇者がメインライン化の必要性に気付いている前提となっています。もしかすると、メインライン化という意識すらない可能性がありますがががが…（割愛）
シナリオ2 メインライン化の作業が楽ではない
皆さんは、最初のスタート地点はここだと思われたかと思います。実際にはシナリオ1で頓挫している現場も多数あるように感じています。スタートラインに立てているならば、なんとかなるでしょう。 - fin-
さすがにそれでは雑すぎるので、作業の中で頓挫してしまう例を上げてみたいと思います。
No1.パッチをどこにどうすれば取り込んでもらえるか分からない。
-> 最初は誰しもがそうですよね。社内にナレッジがある場合は先輩に聞くことで解決できますが、ない場合は調べる他ありません。
ちなみに、ドライバーを新規作成した場合はサブシステムのMLなどに投稿するのですが、これだけで1つの記事が出来上がってしまうので割愛します。
No2.パッチの品質が悪い。
期待した動作するコードが必ずしも、優れたパッチとは限りません。
パッチをMLに投稿してから指摘されることも多いです。むしろ、一発で通すことを目指すというよりレビューを受けて仕上げていく感覚に近いです。
よくある指摘事項は、パッチをもっと分割して。パッチのdiscriptionを充実させて。このアプローチは微妙だからこうしてくれなどがあります。
このリファクタリング作業はこのようにレビューを受けたりするため、そこそこ絶対的に時間がかかることが多いです。そんなに手間かかるならやめたら？という横槍が入ることもあるでしょう。
またQAコストがペイしないと判断されて頓挫してしまうことがあります。（製品に組み込んでいる場合は大抵結合テストが必要だからです。）
本来ならば、メインライン化の作業と製品作りなどは分離して置く必要があるのですが、片手間にどうぞという形だったりする場合は、このようなことが発生することがあるようです。
まだまだあるぞ、現場のあるある。
そもそも、カーネルってバニラの最新のLTSが使えるわけではない。SoCに付随してくるLSPを使わざる得ない。このLSP、何個前のバージョンがベースですか…。なんですか、この独自パッチにまみれたカーネルは。いや、パッチならまだいいけど、Linuxカーネルのお作法とかの概念が存在しねぇ！？おれおれヘルパー関数でサブシステム越境してやがるだと！！なぜ、そこにフック関数が…etc
この辺はx86_64はあんまりないかも知れませんが、ARM SoCだとにゃーんって感じなんですよねー。
力尽きた
書き出すとシナリオがいっぱいあることに気付き、この辺りで書くのに疲れました…。（パタリ）アップストリーム化の作業する上で、バニラのヘッドが使える環境じゃないと大変とかなんか他にもいろいろありそうなのですが…。
この辺誰かもうまとめるような気がするのですが、意外に無いのかな。
0 件のコメント:
コメントを投稿