Jahr 2038 Lösung für Embedded Linux (32 Bit)? [duplicate]
Lesezeit: 5 Minuten
Ian Goldby
Was ist der richtige Weg, um Zeiten in C-Code für 32-Bit-Embedded-Linux (ARMLinux) zu handhaben, um sicherzustellen, dass der Code nach 03:14:07 UTC am 19. Januar 2038 weiterhin ordnungsgemäß funktioniert (wenn eine signierte 32-Bit time_t überläuft)? Angesichts dessen time_t auf dem System, das ich verwenden muss, 32-Bit signiert ist, was sind die Alternativen?
Eine beträchtliche Menge an Google hat nichts von praktischem Nutzen aufgedeckt. Jeder scheint davon auszugehen, dass wir bis dahin alle 64-Bit-Betriebssysteme verwenden werden, aber das gilt offensichtlich nicht für eingebettete Systeme.
Auf dem System, das ich verwenden muss, __kernel_time_t ist definiert als ein long. Was vermutlich bedeutet, dass es keine Kernel-Funktion für 64-Bit-Zeit gibt. Die Version von uClibc ist 0.9.29.
Ich kann nicht glauben, dass ich der einzige mit diesem Problem bin, und ich möchte das Rad nicht neu erfinden.
Ich stimme zwar zu, dass dies eine gute Frage ist, aber für SO könnte sie zu weit gefasst sein. Haben Sie die LKML durchsucht oder eine Anfrage gestellt?
– zu ehrlich für diese Seite
26. Januar 2016 um 14:24 Uhr
@Olaf: Ich habe gelesen, was die Linux-Kernel-Autoren tun, aber das dreht sich alles um 64-Bit-Systeme. Ich denke nicht, dass diese Frage zu allgemein ist; Ehrlich gesagt bezweifle ich, dass es überhaupt so viele verschiedene Möglichkeiten gibt, und die Antwort könnte möglicherweise lauten: “Es gibt derzeit einfach keine universelle Lösung für eingebettete Systeme.”
– Ian Goldby
26. Januar 2016 um 14:37 Uhr
@nm In der Embedded-Welt sind 20 Jahre gar nicht so lange. Eines der Systeme, an denen ich arbeite, ist über 35 Jahre alt.
– Ian Goldby
26. Januar 2016 um 14:46 Uhr
@nm: Überraschenderweise gibt es Anwendungsbereiche, die nicht jedes Jahr ein neues Gerät herausbringen. Denken Sie bei Haushaltsgeräten z. B. an Waschmaschinen (natürlich nicht die billigen) usw.
– zu ehrlich für diese Seite
26. Januar 2016 um 15:01 Uhr
Hallo ab 2021! Linux 5.6 und höher ist bereit, nach dem Jahr 2038 auf 32-Bit-Systemen ausgeführt zu werden: lkml.org/lkml/2020/1/29/355?anz=web
– Emil Cormier
9. April 2021 um 19:35 Uhr
Es gibt keine Patentrezepte, Tricks oder schlaue Lösungen. Verwenden Sie entweder ein Betriebssystem mit 64 Bit time_t oder nicht verwenden time_t und alle Betriebssystemeinrichtungen, die davon abhängen (einschließlich Dateisysteme, Timer, das halbe Netzwerk und dergleichen) oder planen, die Software in den nächsten 20 Jahren zu aktualisieren.
Ich habe dies einfach als Antwort markiert, weil unsere endgültige Entscheidung darin bestand, vorerst mit 32-Bit-Zeit zu leben und uns später um das Problem zu kümmern. Meiner Meinung nach keine großartige Lösung, aber die Komponente, an der ich arbeite, ist nicht die einzige, die betroffen ist.
– Ian Goldby
27. Januar 2016 um 8:25 Uhr
Da ARMLinux anscheinend auf NetBSD basiert, ist man mit der 32bit-Version auf der sicheren Seite. Aber überprüfen Sie dies in der Quelle. Es ist nicht verwunderlich zu glauben, dass 2038 weit in der Zukunft liegt. es ist weniger als 18 Jahre ab jetzt.
– der König2
9. August 2020 um 19:55 Uhr
Hallo ab 2021! Linux 5.6 und höher ist bereit, nach dem Jahr 2038 auf 32-Bit-Systemen ausgeführt zu werden: lkml.org/lkml/2020/1/29/355?anz=web
– Emil Cormier
9. April 2021 um 19:35 Uhr
Zeitkonvertierungsroutinen müssten “einfach” 2038-01-19:03:14:07Z als Basis für die Unix-Epochenzeit verwenden, wenn der Zeitstempel unter einem bestimmten Wert liegt.
Dh wenn Ihr System am 01.01.2010 produktiv geht, können Sie davon ausgehen, dass kein Zeitstempel, der nicht übergelaufen ist, unter 1262300400 liegt (das ist die Unix-Epochenzeit für dieses Datum).
Wenn ein niedrigerer Zeitstempel gefunden wird, gehen Sie davon aus, dass er übergelaufen ist, und verwenden Sie 2038-01-19:03:14:07Z als Basiszeit. Auch Vergleiche müssen berücksichtigt werden.
Keine saubere Lösung, aber mit mäßigem Aufwand machbar. Wechseln Sie besser zu 64-Bit-Zeitstempeln (die nicht unbedingt ein 64-Bit-System benötigen, übrigens).
Dies ist ein schrecklicher Ansatz. Auf meinem Linux-System gibt es eine ganze Reihe von Dateien mit Zeitstempeln aus dem Jahr 1999 oder so. Auch wenn Sie Archive extrahieren, die Sie von woanders bekommen (zB von einer Paketaktualisierung), können die mtimes alle durcheinander gebracht werden.
– fuz
26. Januar 2016 um 14:37 Uhr
@FUZxxl Dem stimme ich zu 😉 Aber wir reden hier von eingebettet, die Auswirkungen sind vielleicht überschaubar
– Ctx
26. Januar 2016 um 14:39 Uhr
Die Auswirkungen unplausibler Zeitstempel aus der Zukunft können fatal sein. Zum Beispiel wirft es komplett ab make oder Backup-Programme, die auf Zeitstempel basieren.
– fuz
26. Januar 2016 um 15:04 Uhr
@FUZxxl: Ich möchte definitiv nicht an diesem Datum reisen: Flugzeuge, Züge und Autos … alle können bis dahin selbstfahrend sein, aber wahrscheinlich nicht immun gegen die Y2G-Mutter der Käfer.
– chqrlie
26. Januar 2016 um 15:07 Uhr
Das ist ziemlich genial, aber möglicherweise ein wenig zu schlau. Es wäre sicherlich eine interessante Überraschung für jeden, der das System nach Ihnen warten muss. Ist dies eine Vorahnung auf einen zukünftigen SO-Posten Ihres Nachfolgers?
– Zhro
26. Januar 2016 um 16:31 Uhr
Ich gehe davon aus, dass die ABI Ihres eingebetteten Systems definiert ist long als 32 Bit.
Es besteht kein Anspruch auf die time_t Typ zu unterschreiben. Könntest du es vielleicht schaffen unsigned long und sich und Ihren Nachkommen zusätzliche 68 Jahre Ruhe erkaufen? Um dies zu ändern, müssten der Kernel, die C-Bibliothek und alle Programme und Bibliotheken, die sie verwenden, neu kompiliert werden time_t… nicht für schwache Nerven! Sie können es genauso gut definieren als long longaber dies würde viele Strukturlayouts ändern und ist noch herausfordernder.
Wenn Sie sich die Mühe machen, jede Binärdatei auf dem gesamten System neu zu kompilieren, warum nicht aktualisieren!?
– Katze
26. Januar 2016 um 16:44 Uhr
@Katze: Guter Punkt! Wenn das OP ausreichende Kontrolle über den Systemsoftware-Stack hat, hat es mehrere Optionen, um das Problem zu verhindern, wobei ein Upgrade eine viel bessere Lösung ist als das Patchen mit Kernel-Typen, wenn er dies nicht tut, kann nicht viel getan werden.
– chqrlie
26. Januar 2016 um 17:57 Uhr
13346100cookie-checkJahr 2038 Lösung für Embedded Linux (32 Bit)? [duplicate]yes
Ich stimme zwar zu, dass dies eine gute Frage ist, aber für SO könnte sie zu weit gefasst sein. Haben Sie die LKML durchsucht oder eine Anfrage gestellt?
– zu ehrlich für diese Seite
26. Januar 2016 um 14:24 Uhr
@Olaf: Ich habe gelesen, was die Linux-Kernel-Autoren tun, aber das dreht sich alles um 64-Bit-Systeme. Ich denke nicht, dass diese Frage zu allgemein ist; Ehrlich gesagt bezweifle ich, dass es überhaupt so viele verschiedene Möglichkeiten gibt, und die Antwort könnte möglicherweise lauten: “Es gibt derzeit einfach keine universelle Lösung für eingebettete Systeme.”
– Ian Goldby
26. Januar 2016 um 14:37 Uhr
@nm In der Embedded-Welt sind 20 Jahre gar nicht so lange. Eines der Systeme, an denen ich arbeite, ist über 35 Jahre alt.
– Ian Goldby
26. Januar 2016 um 14:46 Uhr
@nm: Überraschenderweise gibt es Anwendungsbereiche, die nicht jedes Jahr ein neues Gerät herausbringen. Denken Sie bei Haushaltsgeräten z. B. an Waschmaschinen (natürlich nicht die billigen) usw.
– zu ehrlich für diese Seite
26. Januar 2016 um 15:01 Uhr
Hallo ab 2021! Linux 5.6 und höher ist bereit, nach dem Jahr 2038 auf 32-Bit-Systemen ausgeführt zu werden: lkml.org/lkml/2020/1/29/355?anz=web
– Emil Cormier
9. April 2021 um 19:35 Uhr