Linuxカーネル5.6、32ビット版で2038年問題への対応が行われる 54
ストーリー by hylom
ついに 部門より
ついに 部門より
headless曰く、
Linuxカーネル5.6（Linuxカーネル5.4/5.5にバックポートされる可能性も高い）の32ビット版で2038年問題（Y2038）への対応が初めて行われたという（Arnd Bergmann氏のメーリングリスト投稿、Phoronix、The Register）。
Y2038はUNIX時間が2038年1月19日3時14分7秒（UTC）以降、符号付き32ビット整数で表現できる範囲を超えてしまうという問題だ。OpenBSDは2014年にY2038対応しているが、Linuxの場合64ビットシステムでは64ビット整数が標準のため影響は少ないものの、カーネルとユーザー空間が分かれていることから32ビットシステムでの対応は簡単に進められる問題ではなかったという。なお、2038年に32ビットPCが使われていない可能性は高いが、32ビットの埋め込みシステムが多数残っている可能性もある。
Arnd Bergmann氏らは何年にもわたってY2038対応に取り組んでおり、32ビットシステムでも64ビットのtime_tが使われるようにするなどの修正を進めていた。Bergmann氏によればLinuxカーネル5.6が2038年以降も32ビットシステムで実行可能な初のリリースとなるが、いくつか注意すべき点が残されているという。たとえば、ユーザー空間は64ビットtime_tを使用するようコンパイルする必要がある。また、タイムスタンプに符号付き32ビット整数を使用するファイルシステムの問題など、64ビットシステムに影響する問題は32ビットシステムにも適用されるとのことだ。
カーネルとユーザー空間が分かれている (スコア:1)
BSDはカーネルとuserlandがセットで提供されるからカーネルだけのLinuxより対応が容易だったのか
なぜ無理やり64ビットにしようとする？ (スコア:0)
unsignedにするなら2108年？くらいまでモンダイなくなるのに…。
データのバイナリ互換性も保たれる。
time_tがエラーに-1を使ってる？そんなの
if (t==(time_t)-1)
のようにキャストすれば無問題。C言語規格上もこれが正しかったはず。time_tが符号付きとは規定されていなかった。（最新規格は確認してないが当初の規格では）
Re: (スコア:0)
「年号処理めんどくさいからハードコーディングしたけど、次に年号変わるまでは問題ないからいいよね？」みたいでいやだなぁ
Re: (スコア:0)
そんな議論は７年前に終わっています
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg444471.html [mail-archive.com]
Re: (スコア:0)
リンク先を（Google翻訳使って）見てみたが、同じような提案が行なわれているだけであって、
「終わっている」==「結論が出ている」≒「32ビットunsignedではダメな理由が説明されてる」ようには見えなかったが？
（John Stultz氏の発言にたいしてコメントはついてないように見えるが…見落としてる？）
Re: (スコア:0)
実装が終わってんだから議論が終わったかどうかはどうでもいいんじゃないですかね。
根本的対応で実装されてんだから、文句言う筋合い皆無だし。
Re: (スコア:0)
一部のシステムでは1970年以前を表すのに負値を使ってるって聞いたけど。
明治末あたりから1970年まで。
Re: (スコア:0)
聞いたけど何？それこそ規格外でしょ
Re: (スコア:0)
https://linuxjm.osdn.jp/info/GNU_coreutils/coreutils-ja_207.html [linuxjm.osdn.jp]
GNU を始め、POSIX に準拠したほとんどのシステムでは、 POSIX に対する拡張として、こうした時間表記をマイナスの秒数を使うことも含めて、サポートしている。
従って、‘@-1’ は 1969-12-31 23:59:59 UTC を表すことになる。
少なくともGNUの実装ではマイナス秒はサポート対象
そしてLinuxではそのGNUの実装を使ってる
だから修正も面倒だった
「聞いたけど何？」って言ってる位だから背景からして理解してないのかな？
Re:なぜ無理やり64ビットにしようとする？ (スコア:1)
そうだよ
関数(≒システムコール≒カーネル空間側)は定義通りエラーならtime_t型の-1を返す
このtime_t型は実装上中身が符号付正数だったけど、unsigned化で対応して規格外なんか知らんがなんてことは、例えもともと規定されてなくてもカーネルメンテナが許すわけないので論外
いわゆる「ユーザ空間をぶっ壊す修正」だもの
一方、各ユーティリティ(ユーザ空間側)は、その関数で帰ってくるtime_t型を実装がそうだったから実質的に32bitの符号付正数と決め打ちして型変換せずに扱ってたり、おまけでマイナス秒に対応したりしてた……ので修正がややこしくなった一因となったのよ
Re: (スコア:0)
加減算とかX秒前を表現するときとか、負数を使えた方が便利だからじゃないの。
規格上、time_tは単なる算術型で符号の有無や整数型かどうかは処理系定義だけど、特定の処理系用コードで4byte符号付き整数型を期待するのは間違っていない。
そしてint32_tとtime_tに互換がある前提で書いているコードからしたら、time_tをunsigned にしようが64bitにしようが互換性のない仕様変更なのは変わらない。
もしかして: "組込みシステム" (スコア:0)
>32ビットの埋め込みシステム
"埋め込みシステム"って何だろうと思ってググったら、「もしかして: "組込みシステム"」って教えて貰った。
google先生有能！
Re:もしかして: "組込みシステム" (スコア:1)
> 埋め込みシステム
もしかして「平安京エイリアン」
Re: (スコア:0)
「Embedded」を直訳したんだろうなあ…
Re: (スコア:0)
>昨今は”埋め込み～”が広く使われている。
http://www.de-pro.co.jp/2012/06/08/3605/ [de-pro.co.jp]
いやいやいや。初めて聞いたんだが。もう現役を退いて長いからなぁ…。
Re:もしかして: "組込みシステム" (スコア:1)
Re: (スコア:0)
>"埋め込みシステム"って何だろう
マスクROM(消去不可)とか、UV-EPROM(全消去のみ)とか
実質更新できないプログラムで動いてるシステムの事じゃないかな？
#書き換えできないから、カーネル変わっても更新する手段がないが
#必殺!現地で筐体開けてROM差し替え!!(ソケット代ケチって基板にはんだ付けしてあったり)
Re: (スコア:0)
システム完成後に仕様を知ってる人間を人柱にして埋め込むのが埋め込みシステムだよ。
ほらこのサーバルームで作業してる時、後ろの壁から何か視線を感じない……？
Re:もしかして: "組込みシステム" (スコア:1)
Re:もしかして: "組込みシステム" (スコア:1)
> システム完成後に仕様を知ってる人間を人柱にして埋め込む
違うと言われるかも知れないけど、
エバの マギ システムのこと？
他にもあったような…
maruken
Re: (スコア:0)
納期に間に合わせる為取り合えず版を納入して
あとは担当者がサーバールームに詰めて運用しながら改修する。
#よくある光景です。納入後に仕様変更が来ることも。
Re: (スコア:0)
飛行機の初飛行は、飛行機の制御プログラム開発者をうしろにのせて飛ばせばよさそう
信頼性が上がると思う
ついでに、飛行中に不具合が見つかったらその場で修正
Re: (スコア:0)
「〇〇の言い間違いor書き間違いかな？」と思ってたら実は自分が知らなかっただけでそういう言葉も存在したという経験が何度もあるので「普通の人間は普通に推定」ってけっこう危険です。
ぐぐるは一時の恥、ぐぐらぬは一生の恥
Re:もしかして: "組込みシステム" (スコア:1)
Re: (スコア:0)
くぐるなあぶない（踏切）
Re: (スコア:0)
くくるなあぶない（首）
僕の書いたソフトウェアも20年後に動いているかな (スコア:0)
int now;
time((time_t*)&now);
Re:僕の書いたソフトウェアも20年後に動いているかな (スコア:1)
CPUの汎用レジスタのビット数と、言語・APIのアドレスは別でもいい (スコア:0)
なんかCPUの汎用レジスタのビット数と、開発言語やシステムコールで使う整数型のビット数は
一致させる必要は無いのに、なんで多くの実装で一致させるんだろ？
Re:CPUの汎用レジスタのビット数と、言語・APIのアドレスは別でもいい (スコア:1)
昔はメモリアクセスがずっと遅かった。
16ビットのシステムで32ビットのデータ、あるいは32ビットのシステムで64ビットのデータを扱うとアクセスに2倍より遥かに時間が掛かった。だから仕方なく合わせただけ。で、その遺産が多いからでは。
今は互換性の問題だけだろうけど。
Re: (スコア:0)
今の飽食の時代に育った人が、戦中戦後の食糧不足や江戸時代の飢饉を理解できるわけもなし。
Re: (スコア:0)
速度を無視しても64KByteのRAMが一万円くらいした時代に「整数は基本64bit」なんて企業でも苦しいしねw
Re: (スコア:0)
いまもメモリ(DRAM)アクセスは遅いけど、
L1・L2・L3キャッシュとたくさんキャッシュ積んでごまかしてるだけだよ
Re: (スコア:0)
B言語の頃にはC言語でいうint型しかそもそも整数型がなかった
Re: (スコア:0)
「整数型のビット数」の言葉の意味はよくわからんが、INT型の事なら開発言語は一致してないよ？
レジスタ長64ビットでも、ほとんどの環境では32ビット。
システムコールで使う整数型(？)は、ポインタが格納される可能性があるのでレジスタ(x86の場合はRIP/EIP/IP)のビット数にあわせる必要がある。
Re: (スコア:0)
カオスになるからじゃない？
正直64bitCPUのAndroidでは64bitのOSで64bitのアプリが動いていて欲しい。
Re: (スコア:0)
AndroidはOS(とそこに乗っかるアプリケーション実行環境)の名前なのに「64bitCPUのAndroidでは～」というコメントがすでにひどいカオスになっているw
Re: (スコア:0)
ではここで、android.comの文章を見てみよう。
What is Android
The platform changing what mobile can do.
https://www.android.com/what-is-android/ [android.com]
Android
The platform changing what businesses can do.
https://www.android.com/intl/en_us/enterprise/ [android.com]
この文章を書いた会社はAndroidが何の名前かわかっていないようだ。さらに自分で行った定義を覚えていることもできないのだ。
Re: (スコア:0)
x64やaarch64なんかの64ビットCPUアーキテクチャでのLinuxや各種Unixでは、intが32ビット。お望みどおり「CPUの汎用レジスタのビット数と、開発言語やシステムコールで使う整数型のビット数は一致していない」環境ですよ。
Re: (スコア:0)
ほとんどは「処理が簡単だから」でしょ
コンパイルが必要？ (スコア:0)
組み込みシステムに使い続けられている想定なのに、コンパイルが必要って言われてもなぁと思ってしまった。
組み込みシステムを64bitで出荷すれば済むのでは。値段の差がそんなにあるんだろうか。
Re: (スコア:0)
1ドルの組み込みマイコンで64bitLinuxが動くようになって、2038年までに交換が完了すれば問題なさそう
それかいっそ日付を扱わないシステムにするか
Re: (スコア:0)
Raspberry Pi ZeroWと Raspbery Pi3くらいの値段差と消費電力差があります。
あと、「出荷すれば済む」のに必要な根回しとかを、あなたが担当してくださるのであれば実現可能かと。
Re: (スコア:0)
32bit で保守するコストよりは新規に作っちゃうコストのほうが低いだろうなと思った。
Y2038 (スコア:0)
一瞬FM音源の名前かと思った。
日付をバイナリ形式で保存しているプログラムに重大な影響が出そう (スコア:0)
32bit環境での使用を前提にしていてファイルのフォーマットで日付情報をバイナリ形式で扱ってるシステムだと
いきなりtime_tを32bitから64bitにされたら、日付を読み取り間違えたり、データの位置がずれたりしてファイルが破壊されたり読み出しがおかしくなったりしそう。
SSL認証局の有効期限はいつになれば2038年を超えるの？ (スコア:0)
SSL認証局の有効期限って、どこも横並びで2038年だよね
これって2038年問題の影響なのかな？
Re:SSL認証局の有効期限はいつになれば2038年を超えるの？ (スコア:1)
たぶんそう。ASN.1のUTCTimeデータ型は2038年問題に当てはまらない（もう少し先のはず）のだけれどね。
ファイルシステムの問題 (スコア:0)
ext2とか3の他だとなんだろ？
#NTFSの〜60056年5月28日は草
Re: (スコア:0)
まさか５万８千年後に世界的な問題が発生するとは、この頃は思ってもみなかったのであった・・・