Linuxの旧Arm対応を削除する作業が、具体的なパッチになった。カーネル開発者のArnd Bergmann氏は2026年9月8日、13本の変更案を投稿し、初回の集計で5万5679行を削除すると示した。Linux 7.3での非推奨化から撤去へ進む提案だが、STM32やPXAといった名前を見て、製品系列全体の対応終了と受け取ると範囲を誤る。同じ系列でも残る機種があり、保守が難しいCPUの改訂版や、移行が進まなかった旧式のボード対応が選び分けられている。何を残せるかは、ハードウェアの年齢とともに、現行のLinuxで使い続ける人と実装の状態に左右される。Bergmann氏の提案から、その境目が見える。

AD

13本から始まる整理と、7.4・7.5の役割

初回投稿の変更集計は371ファイル、115行追加、5万5679行削除だ。削る行には実行コードに加え、設定ファイルやハードウェア構成を記すデバイスツリーが含まれる。したがって、この数字はソースツリーの整理規模を表す。カーネルの実行速度や、各機器にインストールするバイナリの縮小量を示す測定値ではない。

しかも、13本は整理全体の最初の一組である。Bergmann氏によれば、作業は予想以上に広がり、手元では300パッチに達している。その中には、さらに小さく分割する必要のある変更もある。今回提出したのは主に機種固有の実装と、削除する設定項目へ直接依存し、容易に除去できる部分だ。

時期は、作業の対象ごとに読む必要がある。9月8日のカバー文は次のように分けている。

工程 対象 投稿時点での説明
非推奨化 古い機種や機能に削除予定を示す Linux 7.3で実施し、LTS向けに対応を残す想定
今回の機種対応削除 機種固有の実装と、直接依存する一部のコード 当初の削除目標は7.4。今回の13本を投稿
後続の整理 使われなくなるドライバーやアーキテクチャ機能 一部は7.4に入り得るが、多くは依存関係を簡単にするため7.5を目標

この表はBergmann氏の初回投稿にある対象と時期を対応付けたものだ。7.5を主な目標とする記述は、今回含めなかった後続の整理を指す。 13本すべての7.5への延期や、いずれかの版への取り込みが確定したという意味にはならない。

機種固有のコードを先に外せば、それだけが使っていたドライバーを後から判別しやすくなる。一方、対応するドライバーがすべて消える前なら、現役の利用者が必要性を申し出る時間も取れる。Bergmann氏は、この猶予にも明示的に言及している。

STM32やPXAで分かれる削除の範囲

STM32では、削除するマイコンと存続するアプリケーション向けSoCが明確に分かれる。PXAでは旧式のボードファイルを外しても、デバイスツリーで起動する機種の対応が残る。各パッチが記す削除対象と存続範囲を対照すると、製品名の一覧だけでは分からない違いがある。

系列 今回外す対応 パッチが明記する存続範囲・区別
PXA 移行されずに残った旧ボードファイル PXA300搭載のRaumfeldスピーカー。PXA250/PXA270の基本対応も残り、外部のデバイスツリーで動く可能性がある
Orion / Dove 残存する旧ボードファイル Orion5xとDoveには、別の機種向けのデバイスツリー対応がある
i.MX31 ARM1136r0を使うSoCの対応 ARM1136r1を使うi.MX35には同じ問題がなく、削除する理由はないと説明
i.MXのMMUなし構成 Cortex-M側でLinuxを動かす対応など 例えばi.MX7DのCortex-M4上でのLinuxと、Cortex-A7上でのLinuxは別の実行経路
STM32 STM32F4/F7/H7のマイコン対応 STM32MP1のCortex-A7、STM32MP2のCortex-A35を使う系列

表は9月8日付のPXA、Orion/Dove、i.MX31、i.MXのMMUなし構成、STM32の各提案に基づく。「残る」は今回の削除範囲についての説明であり、将来の保守保証ではない。PXAの外部デバイスツリーでの動作も、可能性として述べられている。

削除の単位は、製品ブランドより細かい。 同じSoC内でも、メモリ管理ユニット（MMU）を持つCortex-A側と、持たないCortex-M側でLinuxを動かす対応は分けられる。i.MX7Dを使っているという情報だけでは、今回の影響を判断できない。

ほかにも、SA1100やFootbridge、RiscPCが今回の対象に入る。OMAP24xxやAxxiaも含まれ、マイコン側ではLPC18xx系とSAMV7、評価用のMPS2なども並ぶ。ただし、一覧全体を「32ビットArm終了」と読むことはできない。表にあるi.MX35やSTM32MP1のように、今回も残る32ビットCPUの対応があるからだ。

AD

古い対応を残すと、誰の作業が増えるのか

PXAの旧ボードファイルは、2022年の整理時にも削除されず、デバイスツリーへ移行するための出発点として残された。しかし、Bergmann氏によれば、その後も対象ボードは移行されなかった。保存しておくことで将来の移植に役立つという期待が、現実の作業につながらなかったのである。

ボードファイルは、機種ごとの機器構成や初期化処理をカーネル側のコードで記す旧来の方式だ。これに対しデバイスツリーは、接続された周辺機器や割り込みなどをデータとして記述し、カーネルへ渡す。Linuxの公式文書は、ハードウェア構成をボードやドライバーの実装から分離し、機種ごとのハードコードを減らす役割を説明している。共通コードを利用しやすくする仕組みだ。

それでも古いボードファイルが残れば、共通の仕組みを変えるたびに、旧式の記述も追従させる仕事が発生する。今回PXAの削除に賛同したLinus Walleij氏は、固定的なGPIO割り当てをなくすために何度もコードを再構成してきた経験を挙げ、恩恵を受ける人がいないなら続けることに疲れたと返信した。GPIOは周辺機器の制御などに使う汎用入出力端子であり、その扱いを更新する作業が、古い機種の対応にまで及んでいた。

デバイスツリーへの移行が済んでも、CPUそのものの例外は残り得る。Nokia N800/N810につながるOMAP24xxやi.MX31が使うARM1136r0は、その例だ。Bergmann氏の非推奨化パッチは、この改訂版がマルチプロセッサ対応の設定であるCONFIG_SMPと両立せず、後のARMv6kにある拡張を欠くことを示している。機器の接続情報をデータにしても、CPUの違いを吸収するコードは別途必要になる。

一方、少し新しいARM1136r1を使うi.MX35には同じ問題がない。この差を理由に存続させる判断は、経過年数で一律に線を引く方法より具体的だ。どの例外を維持するために、現在の開発者がどれだけ手を動かす必要があるかが問われている。

生産中のマイコンも対象になる理由

LPC18xxとLPC43xxについては、さらに踏み込んだ説明がある。Bergmann氏は削除パッチで、これらのマイコンは2026年時点でも生産中だが、Linuxを動かしている既知の利用者はいないと述べた。製品が市場に残っていることと、その製品上のLinux対応を保守する必要性は一致しない。

STM32向けの提案でも、Bergmann氏は新しいマイコン製品では小型のリアルタイムOS（RTOS）が使われ、Linuxに関係するのはSTM32MP系列だと説明している。ただし、これは提案者が把握する用途と利用実態の説明だ。Linuxの利用台数を調査してゼロと証明したわけではない。

反対に、利用者が見えている古い機種には例外がある。7月の非推奨化提案では、S3C64XXはMark Brown氏が使っているため残し、OMAP1は残存ボードファイルのデバイスツリーへの移行を見込んでいた。古い実装でも、使う人や更新する道筋が具体的なら、判断は変わる。

削除する側にも、残る機器を壊さないための検証が要る。今回のSA1100削除では、時計機能を扱うRTCドライバーのレジスター配置と、機器を識別する互換文字列の整合性が議論になった。Bergmann氏は9月8日の返信で、問題の挙動は変更前にも存在したと説明し、該当する識別子のエントリーを除いたと報告している。新たな実機故障が確認されたという話ではないが、機種を外せば共有ドライバーの条件分岐も点検する必要があることが分かる。

5万行を超える削除も、不要そうなディレクトリーを消せば終わる作業ではない。共用部分を見分けながら、利用者のいない経路を取り除く。この手間こそ、機種対応と後続ドライバーを段階的に整理する理由の一つになる。

AD

LTSを使う前に確かめたい更新経路

今回の提案が直接変えるのは、今後のLinuxで選べるハードウェア対応だ。手元の機器が既存のカーネルで動いている場合、メインラインからコードが削除されただけで、インストール済みのソフトウェアまで消えるわけではない。影響が表れるのは、新しい版へ更新しようとするときである。

Bergmann氏は7.3をLTSとして利用する想定で、旧対応を残してから削除へ進む道筋を描く。ただし、この想定を、そのまま特定機器の保守年数の保証に置き換えることはできない。kernel.orgの説明では、長期保守版は重要な修正を古い系列へ取り込むものであり、選定には製品側の需要やメンテナーの体制などが関わる。7.3の正式な指定と保守終了日は、確定情報を確認する必要がある。

また、機器メーカーやディストリビューションが提供するカーネルには、独自の保守方針がある。メインラインに対応があること、実際に機器で動くこと、修正が継続して届くことは、それぞれ確かめるべき条件だ。古い版で起動できても、その版への更新提供が続くとは限らない。

利用者がまず確認したいのは、搭載チップの系列名から一歩進んだ機種とCPU、そして現在使っているカーネルの提供元だ。デバイスツリーで動くPXAなのか、撤去対象のボードファイルに依存するのか。i.MXのCortex-A側を使っているのか、Cortex-M側でLinuxを動かしているのか。そこまで分かれば、今回の変更が自分の更新経路を断つかどうかを判別できる。

残る利用者が必要な構成と動作状況を示せるか、維持に必要な変更を引き受ける人がいるか。その具体的な情報を、対応するドライバーが消える前の議論へ持ち込めることが、旧機器を新しいLinuxにつなぎ続ける条件になる。