Linuxでの時刻の表現方法のため、署名された32ビットの数値は、2038年1月19日3:14:07UTC以降の時刻をサポートできません。今年の2038年（Y2038またはY2K38）問題は、時間データ型の表現に関するものです。解決策は、64ビットのタイムスタンプを使用することです。
カーネル開発者のArndBergmannのOutreachyインターンとして働きながら、この問題に取り組み始めました。 Outreachyは、新しいプログラマーがオープンソース開発に取り掛かるのに役立つ慈善プログラムです。カーネルプロジェクトのメンターは通常、Arndのような経験豊富なカーネル開発者です。
Y2038問題に取り組むことを選択したのは、カーネル内のすべてのサブシステムに触れることができ、それ以上のものに触れることができたからです。この問題には、ユーザースペース、Cライブラリ、POSIX、およびC標準も含まれます。問題は本当にレイヤー間のインターフェースにあることがわかりました。
その他のLinuxリソース
- Linuxコマンドのチートシート
- 高度なLinuxコマンドのチートシート
- 無料のオンラインコース：RHELの技術概要
- Linuxネットワーキングのチートシート
- SELinuxチートシート
- Linuxの一般的なコマンドのチートシート
- Linuxコンテナとは何ですか？
- 最新のLinux記事
カーネルで1つの問題を解決することは、たった1つのことを伴うことはめったにありません。また、カーネル内の相互に関連するものの複雑さ（変更前に、常にもう1つのクリーンアップが必要です）とコミュニティとの相互作用（特に新参者として当てはまります）も含まれます。
私たちが取り組んだ分野の1つは、仮想ファイルシステム（VFS）でした。 VFSはファイルシステムの抽象化レイヤーです。したがって、ext4などの一部のファイルシステムが32ビットシステムで2038年を超えるタイムスタンプを表すことができる場合でも、それらをサポートするVFSレイヤーがないと表現できません。
VFSへの変更は、コンセンサスを得てマージするのに最も時間がかかったパッチシリーズの1つでした。
問題： iノードタイムスタンプのカーネル内表現はstructtimespecにありました 、Y2038安全ではありません。 提案されたソリューション： 表現をstructtimespec64に変更します 、Y2038安全です。
シリーズの最初のバージョンは2014年にArndによって投稿されました。当時、いくつかの未解決の問題と、タイムスタンプ範囲チェックの追加に関するフィードバックがありました。
2016年1月に、私はこれに対する最初のコメント要求（RFC）を投稿し、上記のアプローチに反対があるかどうかを尋ねました。これは、カーネルコミュニティの典型的なRFCではありませんでした。シリーズのカバーレターは、提案された変更を説明し、変更がどのように行われるかについてのいくつかの例を提供しました。シリーズで何を伝えようとしていたかについて、混乱がありました。
問題を3つの別々の方法で解決するための別のシリーズ（実際には3つ）を投稿しました。これは、コアの問題のみに対処した以前のシリーズの簡素化されたバージョンでした。これも非定型でした。カーネル開発者のThomasGleixnerは、問題を解決するためのアプローチの1つを少し好んだと述べたため、すべてのパッチをこの方法で実行しました。
しかし、変更を行う前に、いくつかの古いインターフェイスを削除する必要がありました。私がこれのシリーズを投稿したとき、Linus Torvaldsはインターフェースの1つ（ current_fs_time（sb））が好きではありませんでした ）タイムスタンプの粒度にアクセスするための引数としてスーパーブロックを使用したため。ただし、タイムスタンプは実際にはiノードの機能であり、スーパーブロックではありません。そこで、このAPIを削除しました。
今、元のシリーズをもう一度やり直す必要がありました。旗の日のパッチを実行することは、問題への強引なアプローチのように見えました。しかし、私たちはまさにそれをすることになりました。 Coccinelleスクリプトを使用して、さらに一歩進んだ。これにより、80を超えるファイルが変更されました。課題は、リグレッションを回避するために変更を基本的なものにすることでした。最終的に2018年6月にパッチをマージすることになり、変更によるリグレッションは聞いていません。
この演習全体の終わりまでに、3つのカーネル内APIを削除し、ファイルシステムのタイムスタンプ処理の一部を再配置し、より大きなタイムスタンプをサポートするように印刷形式を処理し、32ビットアーキテクチャオブジェクトダンプを分析し、少なくとも5つのバージョンのゼロからのシリーズ。そして、これは私たちがカーネルのために解決した問題の1つにすぎませんでした。しかし、Y2038はまだ私のお気に入りのプロジェクトの1つです。
Deepa Dinamaniが、ニュージーランドのクライストチャーチで1月21〜25日に開催されるlinux.conf.auで、時間がなくなるのを防ぐための探求がLinuxカーネルの隅々まで私を導いた方法を紹介します。