Решение 2038 года для встроенного Linux (32 бит)?

Каков правильный способ обработки времени в C-коде для 32-разрядной встроенной Linux (ARMLinux), чтобы код продолжал работать должным образом после 03:14:07 UTC 19 января 2038 года (когда подписанный 32-разрядный time_t переполнение)? Учитывая, что time_t подписан 32-разрядной системой, я должен использовать, каковы альтернативы?Решение 2038 года для встроенного Linux (32 бит)?

Значительное количество поисковых систем не имеет ничего общего с практическим использованием. Кажется, все полагают, что к тому времени все мы будем использовать 64-битные ОС, но это явно не относится к встроенным системам.

В системе, которую я должен использовать, __kernel_time_t определяется как long. Что, предположительно, означает, что нет ядра для 64-битного времени. Версия uClibc - 0.9.29.

Я не могу поверить, что я единственный с этой проблемой, и я не хочу изобретать велосипед.

источник

2016-01-26 Ian Goldby

Хотя я согласен, что это хороший вопрос, он может быть слишком широк для SO. Вы обыскали LKML или отправили запрос? – Olaf

@Olaf: Я читал о том, что делают авторы ядра Linux, но все это вращается вокруг 64-битных систем. Я не думаю, что этот вопрос слишком широк; честно говоря, я сомневаюсь, что в любом случае есть много разных способов сделать это, и ответ вполне может быть: «В настоящее время нет универсального решения для встроенных систем». –

Сейчас 20+ лет –

Нет серебряных пуль, трюков или умных решений. Либо используйте операционную систему, которая имеет 64 бит time_t, либо не используйте time_t и любые объекты ОС, которые зависят от нее (включая файловые системы, таймеры, половину сети и т. Д.) Или планируют обновить программное обеспечение в течение следующих 20 лет.

На 32-битных машинах есть как минимум две unix-подобные системы с 64-битным time_t: OpenBSD и NetBSD. В OpenBSD было несколько разговоров, объясняющих причины этого: http://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html

источник

2016-01-26 15:19:54 Art

Я отметил это как ответ просто потому, что наше окончательное решение состояло в том, чтобы жить с 32-битным временем и теперь беспокоиться о проблеме позже. Не отличное решение IMO, но компонент, над которым я работаю, не единственный, на кого это повлияло. –

Процедуры преобразования времени «просто» должны использовать 2038-01-19: 03: 14: 07Z в качестве основы для времени Unix Epoch, если метка времени меньше определенного значения.

I.e. если ваша система будет работать в 2010-01-01, вы можете предположить, что никакая временная метка, которая не переполнена, ниже 1262300400 (что является временем эпохи unix для этой даты).

Если обнаружена более низкая временная метка, учтите, что она переполнена и использует 2038-01-19: 03: 14: 07Z в качестве базового времени. Следует также учитывать сравнения.

Не чистое решение, но выполнимое с умеренным усилием. Лучше переключитесь на 64-битные временные метки (для которых совсем не нужна 64-битная система, кстати).

источник

2016-01-26 14:28:20 Ctx

Это ужасный подход. В моей Linux-системе есть довольно много файлов с отметками времени в 1999 году или около того. Кроме того, когда вы извлекаете архивы, которые вы получаете из других источников (например, из обновления пакета), mtimes могут быть запутаны. – fuz

@FUZxxl Я согласен;) Но мы говорим о встроенных здесь, воздействие может быть управляемым – Ctx

Влияние неправдоподобных временных меток из будущего может быть фатальным. Например, он полностью отбрасывает «make» или резервные программы, которые работают на основе отметки времени. – fuz

Я предполагаю, что ABI вашей встроенной системы определяет long как 32 бита.

Нет необходимости в типе time_t, который должен быть подписан. Не могли бы вы сделать это unsigned long и купить себе и своим потомкам дополнительные 68 лет спокойствия? Для этого потребуется перекомпилировать ядро, библиотеку C и все программы и библиотеки, которые используют time_t ... не для слабонервных! Вы могли бы также определить его как long long, но это изменило бы многие структуры структуры и еще более сложным.

источник

2016-01-26 15:00:22 chqrlie

Если вам надо перекомпилировать каждый бинарный файл на всей системе, почему бы не обновить? – cat

@cat: хорошая точка! Если OP имеет достаточный контроль над стеком системного программного обеспечения, у него есть несколько вариантов предотвращения проблемы, а обновление - гораздо лучшее решение, чем исправление с использованием типов ядер, если он этого не делает, не так много, что можно сделать. – chqrlie

Решение 2038 года для встроенного Linux (32 бит)?

ответ

Смежные вопросы