ubuntu20.4 のサポートが終了し、LTSは22.04しか使えなくなっています。

[pickamirai]

lld-14でも本の３章が実行できるようにしていただけませんか？

[uchan-nos]

@pickamirai そうしたいのはやまやまなので、ちょっと、ご相談に乗っていただけませんか？

master ブランチで最新の開発環境に対応するようにコードを修正するのは可能なのですが、問題は osbook_... の各タグの存在です。いくら master で修正を加えても、osbook_... が自動的に変更されるわけではありません。かといって、osbook_... を修正してしまうと、書籍の内容とリポジトリの内容が食い違うため、混乱を招くと思っています。

ここについて、良い案が見つからないまま、今に至ります。

[uchan-nos]

良い方法を思いついた気がするのでメモ

• 実現したいこと：Ubuntu の新しいバージョンで MikanOS を開発できるようにする
• 存在する問題：master を更新しても、osbook_dayXX は依然として古いままで、新しい Ubuntu でビルドできない
  • osbook_dayXX にも修正を適用する（Git タグを新しいコミットに移動する）と、書籍上のコードとリポジトリのコードに差が発生して混乱を招く可能性がある
• 解決案：osbook_dayXX からブランチを生やし、そのブランチに修正を加える
  • 例えば osbook_dayXX_dev のようなブランチを作り、新しい Ubuntu でビルドするための修正を加える

この方法であれば、osbook_dayXX はそのままに保全しつつ、「osbook_dayXX_dev はビルド関連の最低限の修正だけが加わっています」ということを分かりやすく伝えられる気がしました。

[yossy201410]

GitHub_Actionを使った変更はどうですか？

[uchan-nos]

@yossy201410 GitHub Action で具体的に何をどうすると何が解決しますか？

[yossy201410]

@uchan-nos GitHub Actionで、ブランチを作成して、そこに自動的に変更みたいなことができた気がします。

[uchan-nos]

@yossy201410 GitHub Action を使うかどうか以前の問題として、Ubuntu の新しいバージョンでビルドできるようにするために、どのような変更が必要なのかの調査が必要と思います。 その調査が終わって、何か定期的に処理すべきものがあれば、そこで初めて自動化の話が出てくるのかなと思っています。

[ponochi]

しばらくローカルでMikan OSを触ってなかったのですが、先程、諸々の環境をGitから クローンしてきてビルドしてみたところ、lld-14でも問題なくビルドおよび実行ができました。

ちなみに、こちらの環境は以下のとおりです。 OS: Pop!_OS 22.04 LTS (ISOイメージのリリース番号は42です) lld: lld-14 (alternativesのリンクで確認。lldのバージョンは14.0.0なので、 　　　　　　　　lld自体がバグフィックスされたとは考えにくい)

Ubuntu本家ではなく派生ディストロなので、本家でビルドできるかというのは 別途検証が必要になるでしょう。

あくまで推測の域を出ないのですが、Ubuntu 22.04がリリースされた後、 カーネルが5系(C言語ベース)から6系(Rustベース)に変わり、さらに 6系もかなりバグフィックスされているので、lld-14に不具合があったというより、 lld自体がカーネルのメモリ管理機構のバグを叩いてしまっていたのではないか、 と思いました。というか、そう考える方が自然な気がします。

とりあえず、https://github/uchan-nos/mikanos-build の手順に沿って ビルドおよび実行してみただけなので、すべてのタグがビルド可能かまでは チェックしていません。個人的にいろいろ作業する前に、タグを切り替えて ビルド可能および実行可能かどうかをチェック(Pos!_OSでですが) してみようと思います。

uchanさんの新しいバージョンのOSでビルドできるようにして、 どのようにそれを公開していくか、という事に関しては引き続き 検討が必要だとは思います。前提として、lld-14でビルドが 全部のタグで通れば、もしかしたら公開方法の検討および実施は そこまで優先度を高くしなくても良いような気がします。

ちなみに、osbook_dayXX_dev のようなブランチを作り、についてですが、 dayXX毎にブランチを生やすと、ブランチが生えすぎて見づらくなるのでは ないかと思うのですが、どうなんでしょうね。個人的にはuchanさんの 仰る方法だと、生やすブランチの数がそこまで多くない場合に有効な 方法だろうなと感じました。もし、生やすブランチが多くなりすぎた場合は、 masterブランチをベースに、修正箇所を反映した最初から最後まで１本通った ブランチを作成した方が見易いのかなぁという気もします。(その方がgit logで 見た時に見易かったり、diffが取りやすいのかなと) もし、新しく１本通ったブランチを作る場合には、tagを打ってしまうと masterブランチのtagと混ざって大変なことになりそうなので、そこは コミットメッセージで"day03a：修正内容はこれこれ"のように、 既存タグと対応させれば良いでしょう。

いろいろ書いてしまいましたが、あくまで個人的な意見なので 参考程度に見ていただけたらと思います。

[pickamirai]

今回改めて実行してみたところ実行成功しました。ありがとうございます。