パスワードを忘れた? アカウント作成
14104379 story
Linux

Linuxカーネル5.6、32ビット版で2038年問題への対応が行われる 54

ストーリー by hylom
ついに 部門より

headless曰く、

Linuxカーネル5.6(Linuxカーネル5.4/5.5にバックポートされる可能性も高い)の32ビット版で2038年問題(Y2038)への対応が初めて行われたという(Arnd Bergmann氏のメーリングリスト投稿PhoronixThe 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ビットシステムにも適用されるとのことだ。

  • by Anonymous Coward on 2020年02月05日 18時36分 (#3756861)

    BSDはカーネルとuserlandがセットで提供されるからカーネルだけのLinuxより対応が容易だったのか

    ここに返信
  • by Anonymous Coward on 2020年02月05日 13時43分 (#3756646)

    unsignedにするなら2108年?くらいまでモンダイなくなるのに…。
    データのバイナリ互換性も保たれる。

    time_tがエラーに-1を使ってる?そんなの
    if (t==(time_t)-1)
    のようにキャストすれば無問題。C言語規格上もこれが正しかったはず。time_tが符号付きとは規定されていなかった。(最新規格は確認してないが当初の規格では)

    ここに返信
    • by Anonymous Coward

      「年号処理めんどくさいからハードコーディングしたけど、次に年号変わるまでは問題ないからいいよね?」みたいでいやだなぁ

    • by Anonymous Coward

      そんな議論は7年前に終わっています

      https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg444471.html [mail-archive.com]

      • by Anonymous Coward

        リンク先を(Google翻訳使って)見てみたが、同じような提案が行なわれているだけであって、
        「終わっている」==「結論が出ている」≒「32ビットunsignedではダメな理由が説明されてる」ようには見えなかったが?

        (John Stultz氏の発言にたいしてコメントはついてないように見えるが…見落としてる?)

        • by Anonymous Coward

          実装が終わってんだから議論が終わったかどうかはどうでもいいんじゃないですかね。
          根本的対応で実装されてんだから、文句言う筋合い皆無だし。

    • by Anonymous Coward

      一部のシステムでは1970年以前を表すのに負値を使ってるって聞いたけど。
      明治末あたりから1970年まで。

      • by Anonymous Coward

        聞いたけど何?それこそ規格外でしょ

        • by Anonymous Coward

          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の実装を使ってる
          だから修正も面倒だった
          「聞いたけど何?」って言ってる位だから背景からして理解してないのかな?

    • by Anonymous Coward

      加減算とかX秒前を表現するときとか、負数を使えた方が便利だからじゃないの。

      規格上、time_tは単なる算術型で符号の有無や整数型かどうかは処理系定義だけど、特定の処理系用コードで4byte符号付き整数型を期待するのは間違っていない。
      そしてint32_tとtime_tに互換がある前提で書いているコードからしたら、time_tをunsigned にしようが64bitにしようが互換性のない仕様変更なのは変わらない。

  • by Anonymous Coward on 2020年02月05日 13時51分 (#3756656)

    >32ビットの埋め込みシステム

    "埋め込みシステム"って何だろうと思ってググったら、「もしかして: "組込みシステム"」って教えて貰った。
    google先生有能!

    ここに返信
  • by Anonymous Coward on 2020年02月05日 17時08分 (#3756799)

    int now;

    time((time_t*)&now);

    ここに返信
  • なんかCPUの汎用レジスタのビット数と、開発言語やシステムコールで使う整数型のビット数は
    一致させる必要は無いのに、なんで多くの実装で一致させるんだろ?

    ここに返信
    • 昔はメモリアクセスがずっと遅かった。
      16ビットのシステムで32ビットのデータ、あるいは32ビットのシステムで64ビットのデータを扱うとアクセスに2倍より遥かに時間が掛かった。だから仕方なく合わせただけ。で、その遺産が多いからでは。

      今は互換性の問題だけだろうけど。

      • by Anonymous Coward

        今の飽食の時代に育った人が、戦中戦後の食糧不足や江戸時代の飢饉を理解できるわけもなし。

      • by Anonymous Coward

        速度を無視しても64KByteのRAMが一万円くらいした時代に「整数は基本64bit」なんて企業でも苦しいしねw

      • by Anonymous Coward

        いまもメモリ(DRAM)アクセスは遅いけど、
        L1・L2・L3キャッシュとたくさんキャッシュ積んでごまかしてるだけだよ

    • by Anonymous Coward

      B言語の頃にはC言語でいうint型しかそもそも整数型がなかった

    • by Anonymous Coward

      「整数型のビット数」の言葉の意味はよくわからんが、INT型の事なら開発言語は一致してないよ?
      レジスタ長64ビットでも、ほとんどの環境では32ビット。

      システムコールで使う整数型(?)は、ポインタが格納される可能性があるのでレジスタ(x86の場合はRIP/EIP/IP)のビット数にあわせる必要がある。

    • by Anonymous Coward

      カオスになるからじゃない?

      正直64bitCPUのAndroidでは64bitのOSで64bitのアプリが動いていて欲しい。

      • by Anonymous Coward

        AndroidはOS(とそこに乗っかるアプリケーション実行環境)の名前なのに「64bitCPUのAndroidでは~」というコメントがすでにひどいカオスになっているw

    • by Anonymous Coward

      x64やaarch64なんかの64ビットCPUアーキテクチャでのLinuxや各種Unixでは、intが32ビット。お望みどおり「CPUの汎用レジスタのビット数と、開発言語やシステムコールで使う整数型のビット数は一致していない」環境ですよ。

    • by Anonymous Coward

      ほとんどは「処理が簡単だから」でしょ

  • by Anonymous Coward on 2020年02月05日 20時45分 (#3756905)

    組み込みシステムに使い続けられている想定なのに、コンパイルが必要って言われてもなぁと思ってしまった。
    組み込みシステムを64bitで出荷すれば済むのでは。値段の差がそんなにあるんだろうか。

    ここに返信
    • by Anonymous Coward

      1ドルの組み込みマイコンで64bitLinuxが動くようになって、2038年までに交換が完了すれば問題なさそう
      それかいっそ日付を扱わないシステムにするか

    • by Anonymous Coward

      Raspberry Pi ZeroWと Raspbery Pi3くらいの値段差と消費電力差があります。

      あと、「出荷すれば済む」のに必要な根回しとかを、あなたが担当してくださるのであれば実現可能かと。

    • by Anonymous Coward

      32bit で保守するコストよりは新規に作っちゃうコストのほうが低いだろうなと思った。

  • by Anonymous Coward on 2020年02月05日 21時03分 (#3756915)

    一瞬FM音源の名前かと思った。

    ここに返信
  • 32bit環境での使用を前提にしていてファイルのフォーマットで日付情報をバイナリ形式で扱ってるシステムだと
    いきなりtime_tを32bitから64bitにされたら、日付を読み取り間違えたり、データの位置がずれたりしてファイルが破壊されたり読み出しがおかしくなったりしそう。

    ここに返信
  • SSL認証局の有効期限って、どこも横並びで2038年だよね
    これって2038年問題の影響なのかな?

    ここに返信
  • by Anonymous Coward on 2020年02月06日 1時16分 (#3757014)

    ext2とか3の他だとなんだろ?
    #NTFSの〜60056年5月28日は草

    ここに返信
    • by Anonymous Coward

      まさか5万8千年後に世界的な問題が発生するとは、この頃は思ってもみなかったのであった・・・

typodupeerror

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

読み込み中...