ハクソク

世界を動かす技術を、日本語で。

カーネルにおける32ビットサポートの未来

2025年9月2日原文(lwn.net)

概要

  • 32ビットシステム は新製品では時代遅れと認識
  • 既存ハードウェアやソフトウェア のサポートが主な理由
  • 高メモリ対応や年2038年問題 など、32ビット維持の課題
  • 多くのアーキテクチャや機能 が段階的に削除予定
  • 今後10年程度 は一部32ビットサポートが継続見込み

32ビットシステムの終焉と今後のカーネルサポート

  • Open Source Summit Europe 2025で Arnd Bergmann が32ビットシステムの現状と今後について講演

  • 新製品での32ビット利用は時代遅れ、既存のハード・ソフトサポートが唯一の理由

  • カーネルのアーキテクチャ全体を統括する立場から、 32ビットサポート削除の議論 が本格化

  • デスクトップやサーバーは 20年以上前から64ビット化、スマートフォンも10年前から64ビット移行

  • Linuxがサポートするのはデスクトップやサーバーだけでなく、 組み込みLinux も存在

    • 組み込みLinuxの 約90%はArmプロセッサ 上で稼働
    • devicetreeファイルが多数蓄積、 armv8(64ビット)のdevicetree数がarmv7(32ビット)を超えたのは昨年
    • pre-armv7アーキテクチャ対応ハードは3種のみ入手可能、だがカーネルコミュニティでは複数サポート継続
    • 生産終了CPUも多いが、 約10種のサポートは即時削除可能 な状況

  • ハードウェアサポートは半減期的に縮小、ユーザーの有無で削除タイミングが決定

  • 32ビットボードの新規サポートは減少傾向、 10枚の64ビットボードにつき1枚程度

  • Arm以外の32ビットアーキテクチャ（arc, microblaze, nios2, openrisc, rv32, sparc/leon, xtensa）は 新製品でRISC-Vに置き換え

  • nommu（メモリ管理ユニットなし）プロセッサ（armv7-m, m68k, superh, xtensa）は 新規開発なし、既存サポートのみ

32ビットアプリケーションとカーネルメモリ管理

  • 更新不能な32ビットアプリ のため、32ビットユーザースペース＋64ビットカーネルの運用を推奨

  • メモリ制約下では 32ビットユーザースペースで消費半減 可能

  • 64ビットカーネルのオーバーヘッドは小さい

  • 32ビットカーネル維持の主な課題

    • メモリ管理サブシステムの複雑化
    • high memoryサポート の必要性：32ビットカーネルのアドレス空間制限で800MB以上の物理メモリ対応が困難
    • 現在のカーネルは最大16GBのメモリをサポートするが、 そのようなシステムは稀
    • 4GB以上のサポートは 近い将来廃止予定

  • 今後のメモリ管理改善案

    • カーネルとユーザースペースで4GBずつ分離（4G/4G方式） の実験的アプローチ
    • densememメモリモデル による2GBまでのサポート、SPARSEMEMモデルの廃止準備
    • high memory廃止後は zramスワップデバイス として余剰メモリ活用案

年2038年問題とその他の課題

  • 2038年問題 のカーネル側対応は2020年に完了、muslやGNU C Libraryも追随

  • DebianやUbuntuは2024年に2038年安全化

  • 依然として多くのパッケージや言語バインディングで未対応バグが残存

  • 32ビットデスクトップは2038年までに消滅予想

  • ビッグエンディアン（big-endian）サポートも32ビット専用で時代遅れ

    • IBMのmainframeやPowerPCのサポートが終了するまでカーネル内で維持予定

今後削除予定のサポート

  • 8CPU超の32ビットシステムサポート
  • armv4プロセッサ （例：DEC StrongARM CPU）
  • 初期armv6 CPU （omap2, i.mx31など）
  • devicetree未対応ボードのサポート全廃
  • Cortex M（nommu）サポートは2年後に廃止予定
  • i486 CPUサポート は現時点では未削除
  • 32ビットCPUでのKVMサポート 削除パッチ送信済だが、PowerPCユーザー1名のため継続

今後の見通しと削除の判断基準

  • armv7システムのサポートは今後10年は継続見込み
  • 他の32ビットアーキテクチャは より早期にサポート終了
  • high memoryサポート廃止は2027年頃、nommuサポートは2028年頃
  • 削除判断はユーザー有無の調査（Web・Git履歴・開発者への確認）に基づく
  • big-endian RISC-V は現時点で未サポート、今後も非対応方針
  • nommu esp32 CPU はパッチ存在も、実用用途なしと判断

参考資料・関連リンク

  • 講演スライドは公開中
  • Bergmannの 2020年時点での考察記事 も参照可能
  • 本イベントへの参加は Linux Foundation の支援によるもの

Hackerたちの意見

ビッグエンディアンがほぼ死にかけてるのはすごいことだよね。もう、8ビットバイトやEBCDICみたいにコンピュータのゴミ箱行きだろうな。メインコアのコンピューティングは、俺が生まれた50年前よりもずっと均質になってる。技術の自然な進化なんだろうね。

└

今残ってるのはUTF-16と非'\n'の改行タイプだけだね。

└

ネットワークプロトコルでは永遠に付き合っていかなきゃならないよね。幸い、ほとんどのソフトウェアからは隔離されてるけど。

└

いい指摘だね。エンジンからエンディアンに関する#ifdefをいくつか削除したところだよ。

└

ビッグエンディアンがほぼ死にかけてるのはすごいね。LTRスクリプトの書き数字にも同じことが当てはまればいいのに。そうすれば、紙の上でも頭の中でも計算がもっと楽になると思う。あと、世界がISO 8601やRFC 3339みたいなまともな日付・時刻フォーマットに落ち着いてくれたらいいな（どっちも、最初の願いが叶ったら逆になるけど）。 それは、非8ビットバイトやEBCDICと一緒にコンピュータのゴミ箱に捨てられる運命だね。非8ビットバイト、特に7ビットバイトのことは全然理解できなかった。CPUやFPGA、カスタムデジタル回路でよく使われるマルチプレクサやデマルチプレクサ/デコーダ回路を考えると、実際に意味がある数字は8だけだよ。3ビットのセレクタコードに対して得られるのがそれだからね。近くの値は4と16だけど、なんで7ビットにしたんだろう？生まれるずっと前に決められたデザインの選択だと思うけど、理由を知ってる人いる？

└

ビッグエンディアンは、IBMがs390xで一流のLinuxサポートを提供するためにリソースを投入し続ける限り残るだろうね。もちろん、ソフトウェアがs390xで動くことを期待しないなら、リトルエンディアンを前提にしてもいいけど、AppleがPowerPCのサポートをやめて以来、ほとんどのソフトウェア開発者はそうしてるし。

nommuを取り除くのはなんか違和感があるな。誰でも十分にやる気があればエミュレーターを書けるようなシンプルなハードウェアでLinuxを動かせることが、個人としてのコントロールを保つ手助けになると思う。物事が複雑になるほど、自由が減っていくからね。これはあまり論理的な考えじゃないけど、なんか気になるんだ。小さなグループの人間が理解できるようなシンプルなオープンな専用ハードウェアで動くPOSIX OSが必要かもしれない。コミュニケーションや簡単なメディア処理、生産性を高めるシステムがね。最近はオープンコンピューティングの転換点にいる気がする。まるで熱湯の中のカエルみたいだ。

└

アクセス可能なオープンハードウェアが必要だよね。実際には従わない一般的な基準に合わせて、プロプライエタリなハードウェアを無理やり使うのはダメだ。オープンソースは一つのことだけど、オープンハードウェアが本当に必要なんだ。フレームワークのラップトップやSystem76のマシンだけじゃなくて、バイナリブロブでロックされてない標準の64ビットオープンソースマザーボードや周辺機器が必要だよ。

└

そのOSはもう存在してるよ。NetBSDはほぼ何にでも動かせるし（例えば、Motorola 68k CPUを搭載したマシンもサポートしてる）。確かに、そういうマシンの多くはMMUを持ってるけど、システムプログラミングに少し知識がある人なら、まだまだ理解できる範囲だと思うよ。

└

POSIX OSが欲しいなら、nommu Linuxはもうそれじゃないよ。fork()がないからね。

└

nommuは面白いコンセプトだけど、実際にはほとんど誰も使ってないし、これから変わるとも思えない。生産環境で使う実際のユースケースがないんだよね。RTOSの方がnommuハードウェアにはずっと適してるし、「本物」のLinuxが動くパーツはどんどん安くなってる。簡単に理解できるハードウェアアーキテクチャが欲しいなら、自分で実装もできるRISC-Vの方が、nommuやそれ以外のARMよりもずっと良く扱えるよ。

└

ZephyrやNuttX、Contikiみたいな他のオープンOSもあるから、Linuxよりもnommuケースにはそっちの方が合ってるかもね？

Hacker Newsで議論の続きを見る