Linuxカーネルを2038年問題に対応させるには

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と同じようにするのだろうか。