【ITニュース解説】Kernel & Embedded News: Arm64 Drops Big-Endian, Boots CPUs in Parallel

今回のニュースは、Arm64アーキテクチャの今後の方向性を決定づける大きな変更、Linuxカーネルの安定化に向けた動き、組み込みシステム開発ツールの進展、そしてソフトウェア開発の基盤を支えるインフラが直面している課題について伝えている。システムエンジニアを目指す上で、これらの動向が将来の仕事にどう影響するかを理解することは非常に重要である。

まず、Arm64アーキテクチャに関する二つの大きな変更点から解説する。一つ目は、Arm64における「ビッグエンディアン」のサポートがLinuxカーネル7.4で廃止されることだ。データの並び順には「ビッグエンディアン」と「リトルエンディアン」という二つの方式があり、コンピュータ内部でのデータの扱い方を定めている。Arm64プロセッサは両方に対応できるが、主流は「リトルエンディアン」であり、ビッグエンディアンモードで動作するArm64システムは非常に限られていた。主に特定のネットワーク機器などで利用されることがあったものの、一般的なLinuxカーネルではほとんど使われておらず、維持コストが高い割にメリットが少ないと判断された。そのため、カーネル開発チームは不要なコードを削除する方針を決定したのだ。この変更は、ビッグエンディアンを利用している非常にニッチな組み込みシステムにとっては、Linuxカーネル7.3以降へのアップグレードが不可能になることを意味する。該当するシステムを使用している開発チームは、リトルエンディアンへの移行を検討するか、古いカーネルバージョンを使い続けるかの判断を迫られることになる。しかし、ほとんどのArm64ユーザーにとっては、カーネルがシンプルになり、効率が向上するメリットがあると言えるだろう。

二つ目のArm64に関する大きな変更は、「並列CPU起動」の実装提案だ。これは、マルチコアプロセッサを搭載したArm64システムが起動する際、複数のCPUコアを同時に（並列に）起動できるようになるというものだ。これまでのArm64システムでは、セカンダリCPUが一つずつ順番に起動するというシリアルなプロセスを踏んでいた。しかし、x86などの他のアーキテクチャでは既に並列起動が実現されており、Arm64もこれに追従することになる。この機能は、PSCI（Platform System Calls Interface）と呼ばれる、ファームウェアとOS間の標準的なインターフェースのCPU_ON呼び出しで渡せるコンテキスト引数を活用して実現される。これにより、各セカンダリCPUが起動に必要な情報を直接ファームウェアから受け取れるようになり、CPU間の同期処理が簡略化され、起動処理のボトルネックが解消される。結果として、システム全体の起動時間が大幅に短縮されることが期待されており、特にコア数の多いサーバーや高速な起動が求められる組み込み製品にとって大きなメリットとなる。測定結果によれば、起動時間が最大で65%も短縮されるケースもあるという。また、セキュリティ面でも、悪意のあるハイパーバイザーが起動後にセカンダリCPUを挿入する攻撃に対する防御策としても機能する。この並列起動機能もLinuxカーネル7.4でのマージが現実的な目標とされている。

次に、Linuxカーネルの最新動向として「Linux 7.3-rc2」のリリースについて触れる。rc（Release Candidate）とは、正式リリース前のテスト版であり、通常、rc2の段階は比較的修正が落ち着く時期だとされている。しかし、今回の7.3-rc2は、リーナス・トーバルズ氏の言葉を借りれば「フルファット」、つまり非常に大規模な修正を含んだリリースとなった。この大量の修正の中には、ファイルシステム、ネットワーキング、BPF、DRM関連などが含まれているが、特に注目すべきはスケジューラに関する修正である。スケジューラは、CPUがどのタスクをいつ実行するかを決定する役割を担っており、システムの性能に直結する重要な部分だ。Linuxカーネル7.2で導入された「キャッシュアウェアなロードバランシング」は、複数のCPUコアが共有するラストレベルキャッシュを考慮して、関連するタスクを同じキャッシュを共有するコアに集めることで、データアクセスの効率を高めようとする機能だ。しかし、今回の修正では、特に性能の異なる種類のCPUコアを組み合わせた「ハイブリッドCPU」において、キャッシュ効率を優先するあまり、タスクがその性能に見合わない小さなコアに割り当てられ、結果的に性能が低下する可能性が指摘された。この問題を解決するため、修正版では、タスクの性能要件とCPUコアの能力をより適切に判断し、ミスマッチなタスクの移動を避けるロジックが導入された。この修正は、デスクトップPCだけでなく、Armのbig.LITTLEやDynamIQアーキテクチャを採用した組み込みシステムにも直接影響するため、システムエンジニアは自身の製品での性能評価を慎重に行う必要があるだろう。

組み込みシステム開発の現場で広く利用されるビルドツールである「Buildroot」の最新バージョン「2026.08」もリリースされた。Buildrootは、特定のハードウェア向けにLinuxシステム全体を構築するためのフレームワークである。今回のリリースでは、約1000件の変更が含まれており、特にツールチェイン（ソフトウェアをコンパイル・リンクするためのツール群）の更新が重要だ。具体的には、Linuxカーネル7.1.xのヘッダファイル、Binutils 2.46.1、デフォルトがGCC 15になったことと、GCC 16.2.0が選択可能になったこと、glibc 2.44などへの対応が挙げられる。さらに、新しいアーキテクチャのサポートや、Hare言語で書かれたパッケージのためのインフラ、libudev、SDL3のパッケージも追加された。一方で、いくつかのボードのデフォルト設定が削除されているため、これらに依存していたプロジェクトは注意が必要だ。新しいコンパイラの採用は、既存のコードに潜在していた警告や、これまでは気づかれなかったコンパイル時の問題を表出させることがあるため、バージョンアップを行う際には、完全なイメージの再ビルドと十分なテストが不可欠となる。Buildrootのリリースサイクルは比較的速いため、長期サポート（LTS）版を利用するか、頻繁なアップデートに対応できる体制を整えることが求められる。

最後に、オープンソースソフトウェア開発の基盤を支える「kernel.org」が直面している新たな課題について解説する。kernel.orgは、Linuxカーネルのソースコードをホスティングしている非常に重要なサイトであり、世界中の開発者が日々アクセスしている。しかし、最近になって「AIクローラー」と呼ばれる、AIモデルの学習データ収集を目的とした自動プログラムが、git.kernel.orgのリソースを大量に消費していることが明らかになった。kernel.orgの管理者によると、1日に約600万件のリクエストがあり、そのうち正規の人間によるアクセスはわずか2%程度に過ぎないという。AIクローラーは、個々のコミット履歴をウェブページとして取得するために、非常に非効率な方法でアクセスしている。本来なら一つのgitリポジトリをクローンするだけで入手できるはずの大量のデータを、ウェブインターフェース経由で一つ一つのページをたどる形で取得しているのだ。この非効率なアクセスと、IPベースのブロックを回避する技術が、サーバーに莫大な負荷をかけている。実際、kernel.orgのCPUコアの約20%が、AIクローラー向けにHTMLをレンダリングするためだけに費やされているという。この状況に対応するため、kernel.orgはクローラーがアクセスできるURLを減らすなど、高コストな操作に対して制限を設ける方針だ。これにより、匿名ユーザーがウェブインターフェースから利用できる機能が一部制限される可能性がある。この問題は、システムエンジニアが開発ワークフローを見直すきっかけとなる。具体的には、外部のサービスに直接依存するのではなく、社内ミラーを立てて利用する、あるいはスクリプトがウェブインターフェースに依存している場合はローカルクローン上で操作するように変更するなど、より「行儀の良い」アクセス方法を採用することが求められる。これは、日々の開発活動の安定性を確保する上で重要な教訓となるだろう。

これらのニュースは、Linuxカーネル開発が常に進化し続けていること、そしてその進化が組み込みシステムやサーバーといった多様な領域に影響を与えることを示している。同時に、オープンソースプロジェクトの持続可能性を脅かす新たな課題も浮上している。システムエンジニアを目指す者として、これらの技術動向とそれに伴う変化を理解し、適切に対応していく能力を養うことが不可欠である。