Разработчик Debian GNU/Hurd рассказал о проблемах портирования SysV init
В недавно завершившемся обсуждении по выбору системы инициализации для дистрибутива Debian, довольно часто фигурировал аргумент «система инициализации должна быть переносимой» (то есть работать на платформах, отличных от Linux). При этом подразумевалось, что SysV init является переносимой системой инициализации. Однако Юстас Винтер, один из разработчиков порта Debian GNU/Hurd, пояснил, что такое представление является некорректным. Используемая в Debian реализация SysV init жестко завязана на особенности ядра Linux, и обеспечить ее корректное портирование на другие платформы весьма проблематично. Более того, для систем на основе микроядра, в силу архитектурных особенностей реализации, более оптимальным решением является systemd.
Код SysV init, используемый в Debian, во многих аспектах жестко завязан на архитектуру платформы Linux. В качестве наиболее типичного примера такой привязки приводится использование procfs (в файлах src/{bootlog, hddown, killall5}.c). Структура procfs не стандартизирована, и отличается на различных платформах, в частности, Linux и FreeBSD. Во FreeBSD, для запуска не модифицированных Linux-программ, используется специальный слой бинарной совместимости, который, в частности, включает linprocfs — эмулятор структуры procfs, специфичной для Linux. Этот же механизм используется и в Debian GNU/kFreeBSD.
Разработчики порта Debian GNU/Hurd пошли аналогичным путем, создав драйвер procfs, эмулирующий procfs ядра Linux на системе Hurd. «SysV init работает на нашей системе не потому, что он переносим, а потому, что мы ввели ряд хаков для эмуляции особенностей Linux» — отмечает Юстас. Также он упоминает, что procfs является далеко не единственным примером жесткой завязки кода SysV init на особенности платформы.
Но такие, чисто технические, неувязки — далеко не самая значительная проблема. Гораздо более серьезные затруднения создают архитектурные особенности SysV init. Например, при завершении работы системы, программа killall5 убивает практически все процессы в пространстве пользователя. Для системы с монолитным ядро такой подход вполне приемлем, но в системе с микроядром, где работа корневой файловой системы обеспечивается не модулем ядра, а процессом, подобная практика создает некоторые проблемы.
В свете вышесказанного, наиболее эффективным является подход, реализованный в systemd: все процессы структурируются при помощи иерархии контрольных групп, что позволяет останавливать только те процессы, которые нужно остановить на данном этапе, не затрагивая жизненно важные элементы системы. Для обеспечения аналогичной функциональности на Hurd-системах, подготовлена реализация cgroupfs для Hurd.
Полный текст статьи читайте на OpenNet
