System call conversion for year 2038 [LWN.net]
lwn.netでLinuxカーネルを2038年問題に対応させるにはという記事が公開されている。
32bit版Linuxカーネルのtime_tはsigned 32 bitなので、現行の32bit版Linuxカーネルをそのまま使い続けるシステムは、2038年問題の影響を受ける。
問題の日付が近づくにつれ、32bitシステムは様々な楽しげな理由により障害を起こすことが予測されるので、今日のLWN読者は、退職から呼び戻されて、紀南を救うために英雄的な活躍をするだろう。今対策をしなければの話だが。
さて、32bit Linuxカーネルでも、time_tなどの時間の表現に64bitの値を使えば2038年問題は解決できるか。実は、問題はそれほど単純ではない。
カーネル内部の時間表現を64bitに移行するだけではない。ユーザースペースのインターフェースも変えなければならない。いずれは移行しなければならないとしても、現行のバイナリとのABI互換はどうするのか。
このために、すべての時間を扱うシステムコールを、カーネル内部の64bit表現と、従来の32bit表現との変換を行う変換レイヤーとしてのシステムコールで置き換える。64bit時間表現のシステムコールには新しいシステムコール番号を割り当てる。もちろん、2038年までしか使えない。
最終的には、既存のバイナリは一掃される。
ところで、時間を扱うシステムコールと簡単に言うが、すべてを洗い出すのは難しい。ioctlには、現在何千も登録されているが、その一部は時間を扱っている。これをすべて洗い出して直していかねばならない。
ext4はタイムスタンプを32bitのtime_t型で格納している。ディスク上の表現として34bitに拡張しているバージョンのext4もあるが、ext3はそういう対応はしていない。ext3は使用を辞めなければならない。NFSv3も同様の問題があり、おそらく同じ道をたどるだろう。XFSは変更に問題を抱えている。ファイルシステムの問題は、64bitシステムにも影響を及ぼす。他にも、ユーザースペースとカーネルスペース両方で問題になる場面が多々あるだろうは疑う余地がない。そのため、2038年にシステムを対応させるのは、単にシステムコールを64bit値に移行する以上の問題がある。とはいえ、システムコールを直すのは、まず第一歩である。
2038年問題、一体どうなるのだろう。ファイルシステムのようなものは切り捨てるしかないのだろうか。NTPはどうするのだろう。GPSと同じようにするのだろうか。
ドワンゴ広告
ドワンゴは本物のC++プログラマーを募集しています。
CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0
RFC 4330 section 3での回避方法の記述はあるみたいですが、さてどうなるやら
ReplyDelete既得利権と革新派の対立のようですね。
ReplyDeleteディスク上の表現として34bitに拡張しているバージョンのext4もあるが、ext3はそういう対応はしていない。
ReplyDeleteこれは本当に34bit？
ファイルシステムのタイムスタンプは不自由なOSのほうが圧倒的に進んでいるのですね。FATですら2107年まで対応している。
ReplyDelete32bit Linuxがすべて2038年問題を抱えているわけではない。近年追加されたアーキテクチャーは最初からtimespec_tが64bitになっているし、x86の世界でもx32というABIを使えばlong, pointerは32bit幅であるが、時刻は64bitというもの。ただしCPUが64bit対応していないと使えない。ABI specでR0-R7が使えることになっているから。一時期Intelが強力に推進していたが今は熱が冷めている模様
ReplyDeleteところで、FedoraやUbuntuといったデスクトップ向けディストロでは32bitバージョンはメモリが2GB以下の人向けなどと極めて限定した対象向けへの配布にシフトしているので、この分野で32bitバージョンが2038年まで生き残るかはかなり怪しい。
実質的に対応のモチベーションが生じているのはARM 32bitぐらいではないか？
ARM も x32 的な感じで ARM32 (Aarch32ではなく) とか出たりしないんですかねえ。
ReplyDelete