Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
GBP
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
>
2038: остался всего 21 год

2038: остался всего 21 год

05 Май 2017

Порой кажется, что на фронте борьбы с проблемой 2038 года наступило относительное затишье. Однако время идет, и тот день, когда 32-битные значения типа time_t больше не смогут корректно отображать даты, наступит уже меньше, чем через 21 год. Этот срок может показаться большим, однако сравнительно долгий жизненный цикл многих встраиваемых систем подразумевает, что некоторые из них, будучи введенными в строй в наше время, все еще будут работать, когда наступит критический момент. Арнд Бергманн - один из основных разработчиков, занимающихся этой проблемой. На конференции Linaro Connect 2017 он поделился новостями о текущем положении дел в этой области.

Оригинал данной статьи был опубликован на сайте lwn.net. Статья публикуется под CC-SA license.

0505_2038_only_21_years_away_ru/image1.png

Согласно Бергманну, работа ведется сразу в трех независимых направлениях, первое из которых - само ядро Linux. В течение последних пяти лет он искал способы подготовить ядро к 2038 году. Значительная часть этой работы подразумевает конвертирование 32-битных меток времени (timestamps) в 64-битные значения - даже на 32-битных системах. Некоторые 32-битные метки времени также используются в пользовательских API, что значительно усложняет проблему. У Бергманна есть план по улучшению таких API за счет приспособленных к 2038 году версий проблемных системных вызовов, но эти изменения еще не были применены, за исключением недавно добавленного системного вызова statx() в версии 4.11, который заменит семейство вызовов stat(). В то же время остается немало других системных вызовов, нуждающихся в такой замене.

Дипа Динамани также занимается решением проблем, связанных с ядром. Она начинала в качестве стажера по программе Outreachy и по окончании стажировки продолжила работать над этой задачей. Динамани решила одну из самых сложных проблем, разработав собственный набор патчей для прослойки виртуальной файловой системы, и также планирует заняться другими системными вызовами. Вызов setsockopt(), среди прочих, может представлять особую трудность: его не так-то легко поправить или эмулировать на уровне glibc. Заметный прогресс есть в работе по созданию патчей для модуля device mapper и подсистемы ввода. Бергманн также написал патч для подсистемы video4linux, но он был отклонён и требует другого подхода. Примерно так же обстоят дела со звуковой подсистемой. Другими проблемными компонентами ядра являются система управления ключами и часы реального времени.

Некоторые системные вызовы не получат замены, поскольку для них лучшим решением оказывается эмуляция в библиотеках C - это второе направление в подготовке к 2038 году. Бергманн отметил, что сообщество glibc проделало особенно большую работу в этой области. На уровне библиотек планируется обеспечить полную обратную совместимость. Это означает, что можно будет собирать программы как с 32-битными, так и с 64-битными метками времени, при этом последние можно использовать даже в старых версиях ядра. Другими словами, разработчики glibc ищут решения, которые бы работали на всех платформах и с минимальными искажениями. (Подробности можно узнать из черновика проекта).

Третье направление связано со сборками дистрибутивов, причем настоящий прогресс здесь возможен только после того, как будут решены первые две задачи. По мнению Бергманна, маловероятно, что авторы дистрибутивов все еще будут поддерживать 32-битные системы в 2038 году, так что у них нет причин для беспокойства. Единственным исключением может стать дистрибутив Debian, авторы которого, похоже, заинтересованы в продолжении поддержки, даже несмотря на очевидную трудоемкость этого процесса. В какой-то момент может потребоваться полная пересборка, что едва ли обрадует как авторов, так и пользователей, но это решение, по крайней мере, гарантированно работает. В такой системе ключевым условием является обеспечение совместимости; сейчас в эксплуатацию вводится код, который может быть не приспособлен к наступлению 2038 года, но хочется, чтобы он, по возможности, работал и дальше.

Автомобильные системы - еще одна большая проблемная область. Многие устройства, например мобильные телефоны, перестанут работать к 2038 году по многим другим причинам, так что нет смысла готовить их к его наступлению. Однако автомобили находятся в эксплуатации гораздо дольше. В ходу по-прежнему могут быть камеры, и очень вероятно, что будет существовать множество тесно интегрируемых систем, например, в инфраструктуре зданий. Некоторые из таких систем подвергнутся сбоям в 2038 году. Вот почему так важно решить проблему как можно скорее.

В то же время с исправлением некоторых компонентов возникнут трудности, даже когда задачи по подготовке ядра, библиотек C и дистрибутивов будут в основном решены. Многие из этих трудностей связаны с использованием 32-битных значений типа time_t в форматах файлов. Например, cpio сломается, что вызовет определенные проблемы, так как он используется в формате RPM-пакетов. В файловых системах NFSv3, ext3 и XFS тоже будут наблюдаться сбои из-за использования 32-битных меток времени. Первые две системы, вероятно, выйдут из употребления задолго до начала 2038 года, а для XFS уже разрабатываются варианты решений. Наконец, есть множество приложений, пока не попавших в поле зрения разработчиков, а также корпоративных систем, к которым у сообщества нет доступа.

Когда Бергманна спросили, какими инструментами он пользуется в своей работе, он ответил, что основной подход заключается в сборке ядра с полностью удаленными 32-битными типами, отвечающими за представление времени: так можно сразу выявить места, подлежащие правке. В остальном же исправления осуществляются по большей части вручную. Предполагается, что плагины для sparse или GCC могут помочь в решении этой задачи.

В конце выступления Джон Шульц спросил, могут ли наработки сообщества BSD, которое (в некоторых версиях) уже решило проблему 2038 года, помочь Linux. Бергманн ответил, что помощь будет "незначительной". У BSD-дистрибутивов есть то преимущество, что они могут пересобраться с нуля, так что у них нет необходимости поддерживать совместимость с пользовательскими ABI тем же способом. Их опыт по подготовке приложений к 2038 году не лишен ценности, но неизвестно, насколько полезным он окажется для сообщества Linux.

Примечание команды PVS-Studio. Нас заинтересовала эта проблема и мы планируем реализовать в анализаторе PVS-Studio диагностику, которая будет предупреждать об использовании 32-битных переменных типа time_t.

Популярные статьи по теме
Статический анализ как часть процесса разработки Unreal Engine

Дата: 27 Июн 2017

Автор: Андрей Карпов

Проект Unreal Engine развивается - добавляется новый код и изменятся уже написанный. Неизбежное следствие развития проекта - появление в коде новых ошибок, которые желательно выявлять как можно раньш…
Главный вопрос программирования, рефакторинга и всего такого

Дата: 14 Апр 2016

Автор: Андрей Карпов

Вы угадали, ответ - "42". Здесь приводится 42 рекомендации по программированию, которые помогут избежать множества ошибок, сэкономить время и нервы. Автором рекомендаций выступает Андрей Карпов - тех…
Как PVS-Studio оказался внимательнее, чем три с половиной программиста

Дата: 22 Окт 2018

Автор: Андрей Карпов

PVS-Studio, как и другие статические анализаторы кода, часто выдаёт ложные срабатывания. Но не стоит спешить считать странные срабатывания ложными. Это короткая история о том, как PVS-Studio вновь ок…
Зло живёт в функциях сравнения

Дата: 19 Май 2017

Автор: Андрей Карпов

Возможно, читатели помнят мою статью под названием "Эффект последней строки". В ней идёт речь о замеченной мной закономерности: ошибка чаще всего допускается в последней строке однотипных блоков текс…
Технологии, используемые в анализаторе кода PVS-Studio для поиска ошибок и потенциальных уязвимостей

Дата: 21 Ноя 2018

Автор: Андрей Карпов

Краткое описание технологий, используемых в инструменте PVS-Studio, которые позволяют эффективно обнаруживать большое количество паттернов ошибок и потенциальных уязвимостей. Статья описывает реализа…
Бесплатный PVS-Studio для тех, кто развивает открытые проекты

Дата: 22 Дек 2018

Автор: Андрей Карпов

В канун празднования нового 2019 года команда PVS-Studio решила сделать приятный подарок всем контрибьюторам open-source проектов, хостящихся на GitHub, GitLab или Bitbucket. Им предоставляется возмо…
PVS-Studio ROI

Дата: 30 Янв 2019

Автор: Андрей Карпов

Время от времени нам задают вопрос, какую пользу в денежном эквиваленте получит компания от использования анализатора PVS-Studio. Мы решили оформить ответ в виде статьи и привести таблицы, которые по…
Как и почему статические анализаторы борются с ложными срабатываниями

Дата: 20 Мар 2017

Автор: Андрей Карпов

В своей предыдущей статье я писал, что мне не нравится подход, при котором статические анализаторы кода оцениваются с помощью синтетических тестов. В статье приводился пример, воспринимаемый анализат…
Эффект последней строки

Дата: 31 Май 2014

Автор: Андрей Карпов

Я изучил множество ошибок, возникающих в результате копирования кода. И утверждаю, что чаще всего ошибки допускают в последнем фрагменте однотипного кода. Ранее я не встречал в книгах описания этого …
PVS-Studio для Java

Дата: 17 Янв 2019

Автор: Андрей Карпов

В седьмой версии статического анализатора PVS-Studio мы добавили поддержку языка Java. Пришло время немного рассказать, как мы начинали делать поддержку языка Java, что у нас получилось и какие дальн…

Комментарии (0)

Следующие комментарии

На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Этот сайт использует куки и другие технологии, чтобы предоставить вам более персонализированный опыт. Продолжая просмотр страниц нашего веб-сайта, вы принимаете условия использования этих файлов. Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте данный сайт. Подробнее →
Принять