私に起こった面白い状況と、有名なプロジェクトの貢献者になる方法についてお話します。
少し前まで、私は UEFI から直接 Linux をブートするというアイデアを考えていました...
このアイデアは新しいものではなく、このトピックに関するマニュアルが多数あります。 そのうちのXNUMXつを見ることができます
実際、この問題を解決しようとする私の長年の試みは、完全に形式化されたものになりました。 。 このソリューションは非常にうまく機能しており、自宅のマシンの一部で使用しています。 この解決策についてもう少し詳しく説明します。 .
UEFI-Boot の本質は、ESP (EFI システム パーティション) パーティションが /boot ディレクトリと結合されることです。 それらの。 すべてのカーネルとブートストラップ イメージ (initrd) は同じパーティション上に配置されており、UEFI はそこから実行可能ファイルを起動でき、特にシステム ブート ローダーを起動できます。 ただし、多くのディストリビューションの Linux カーネル自体は、UEFI からカーネル自体を起動できるようにする UEFISTUB オプションを使用してすでにアセンブルされています。
この解決策には不快な点が 32 つあります。ESP パーティションは FATXNUMX でフォーマットされており、その上ではハード リンクを作成できません (システムは initrd の更新時に定期的に作成します)。 これについては特に犯罪的なことはありませんが、カーネル コンポーネントを更新するときにシステム警告が表示されるのはあまり気持ちの良いものではありません...
別の方法もあります。
UEFI ブート マネージャー (OS ブートローダーを登録する必要があるマネージャーと同じもの) は、ブートローダー/Linux カーネルに加えて、ドライバーもロードできます。 したがって、/boot があるファイル システムのドライバーをロードし、そこから UEFI を使用してカーネルを直接ロードできます。 もちろん、ドライバーは ESP パーティションに配置する必要があります。 これは、GRUB などのブートローダーが行うこととほぼ同じです。 ただし、ハイライトは、頻繁に使用される GRUB 関数がすべてすでに UEFI に組み込まれていることです。 より正確には、ダウンロードマネージャー内です。 さらに退屈なことに、UEFI ブート マネージャーには、いくつかの点でさらに多くの機能があります。
美しい解決策のように見えますが、「しかし」が 1 つあります (というより、実際にはそうでしたが、それについては後ほど説明します)。 実際、UEFI ドライバー システムは非常にシンプルです。 ファイル システムをマウントしたり、ドライバーを特定のデバイスに関連付けたりすることはできません。 Map という従来の名前のシステム コールがあり、各ドライバを順番に受け取り、少なくとも適切なすべてのデバイスに関連付けようとします。 そして、ドライバーがデバイスを選択できた場合、マッピング、つまり接続レコードが作成されます。 これはまさに、新しくロードされたドライバーが他のすべてのドライバーと共通のヒープ内で初期化される方法です。 必要なのは、ドライバー ブート レコードの XNUMX つのビット (LOAD_OPTION_FORCE_RECONNECT) を XNUMX に設定することだけです。UEFI は、ロード後にこのグローバルな再マップを実行します。
しかし、これはそう簡単ではありません。 標準の efibootmgr ユーティリティ (UEFI オフロード マネージャーの構成に使用されます) は、このビットを設定する方法を知りません (または、むしろ、方法を知りませんでした)。 かなり複雑で危険な手順を経て手動でインストールする必要がありました。
そしてもう一度、自分の手でやろうとしたところ、我慢できずに形式的にやってしまいました。 開発者にこの機能を追加するよう求めています。
数日経ちましたが、誰も私の要求に耳を傾けませんでした。 そして、好奇心から、ソースコードを調べました...それをフォークして、この機能を追加する方法を膝の上で考え出しました...「膝の上」、なぜなら私はそのようなものをインストールせずにソースを編集したからですブラウザで直接コードを記述します。
私は C (プログラミング言語) について表面的には知っていますが、おおよその解決策 (主にコピーアンドペースト) を描いてみました...そして、少なくともそこには多くの間違いがあるだろうと思いました (過去に他の人のコードを編集しようとしたことがありました) Cコードは10回目くらいで完成しました）プルリクエストを出してみます。 良い .
そして、そこにはプルリクエストをチェックするために Travis CI が接続されていることが判明しました。 そして彼は私の間違いをすべて熱心に教えてくれました。 既知のエラーがある場合は、それを修正する必要はありません。やはり、ブラウザ内で、XNUMX 回目の試行でコードが機能しました (私にとっては成果です)。
そのようにして、ブラウザを離れることなく、非常に本物のプル リクエストを、ほとんどすべての最新の Linux ディストリビューションで使用されるユーティリティにフォーマットしました。
私は、言語をよく知らず、何も設定せず (依存関係にはアセンブリにかなりの数のライブラリが必要です)、コンパイラを実行することさえせずに、完全に機能する便利な機能を単に「コーディング」したという事実に驚きました。ブラウザ。
しかし、19年2019月XNUMX日以降、私のリクエストは返信されず、すでにそのことを忘れ始めていました。
しかし昨日、このリクエストはマスターに追加されました。
それで、私の話は何についてですか？ そして彼は、現代のテクノロジーの枠組みの中で、開発ツールや依存関係をローカルにデプロイしなくても、実際のコードはすでにブラウザーで記述できることが判明したという事実について話しています。
さらに、これはすでに有名な (少なくとも狭い範囲での) ユーティリティに対する XNUMX 回目のプル リクエストであることを認めなければなりません。 前回、SyncThing Web インターフェースのいくつかのフィールドの表示を修正するという私のリクエストは、まったく知らない環境で文字通り XNUMX 行の編集という結果になりました。
登録ユーザーのみがアンケートに参加できます。 お願いします。
もっと書いたほうがいいのか、書かないほうがいいのか？
-
はい
-
それほど価値がない
294 人のユーザーが投票しました。 138名のユーザーが棄権した。
出所： habr.com