Порой кажется, что на фронте борьбы с проблемой 2038 года наступило относительное затишье. Однако время идет, и тот день, когда 32-битные значения типа time_t больше не смогут корректно отображать даты, наступит уже меньше, чем через 21 год. Этот срок может показаться большим, однако сравнительно долгий жизненный цикл многих встраиваемых систем подразумевает, что некоторые из них, будучи введенными в строй в наше время, все еще будут работать, когда наступит критический момент. Арнд Бергманн - один из основных разработчиков, занимающихся этой проблемой. На конференции Linaro Connect 2017 он поделился новостями о текущем положении дел в этой области.
Оригинал данной статьи был опубликован на сайте lwn.net. Статья публикуется под CC-SA license.
Согласно Бергманну, работа ведется сразу в трех независимых направлениях, первое из которых - само ядро 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.