Разработчики Gentoo официально анонсировали проект eudev, не зависящий от systemd
Несмотря на то, что udev по-прежнему доступен для обособленного использования и может работать без привязки к особенностям systemd, недовольство вызывает разработка udev с оглядкой на новые версии ядра Linux, что часто нарушает совместимость со старыми системами. При этом, по мнению разработчиков Gentoo, привязка к новым возможностям ядра Linux не всегда оправдана и привносится даже тогда, когда зависимости от новых версий ядра можно избежать. Подобная тенденция стала наблюдаться после перехода udev под крыло проекта systemd, разработчики которого не заинтересованы в предоставлении полной поддержки в udev систем, выступающих в роли альтернативы systemd.
Eudev будет развиваться как проект группы заинтересованных разработчиков из сообщества Gentoo с целью предоставления альтернативного решения, которое со временем может быть одобрено для интеграции в дистрибутив Gentoo. Мэйнтейнерам используемого в настоящее время пакета udev не навязывается переход на форк, тем не менее разработчики eudev намерены показать, что в поддержании systemd-udevd вне пакета systemd нет необходимости, когда есть eudev. В конечном счёте, будет ли дистрибутив переведён на eudev или останется на systemd-udevd зависит от решения консультативного совета Gentoo.
Eudev будет развиваться без привязки к технологиям Gentoo, что позволит использовать его и в других дистрибутивах Linux. Первое время развитие будет нацелено на обеспечение работы в Gentoo, но это не исключает приём исправлений для ошибок, специфичных для других дистрибутивов. После того, как работа eudev в Gentoo будет признана стабильной планируется наладить сотрудничество с разработчиками других дистрибутивов с целью привлечения их к разработке проекта. В идеале, eudev можно будет использовать для прозрачной замены systemd-udevd. Для упрощения участия в проекте сторонних разработчиков в качестве платформы для размещения репозитория решено использовать GitHub. Разработчики eudev готовы к интеграции поддержки интересных другим дистрибутивам возможностей, за исключением необоснованных предложений (например, желании интегрировать в eudev собственную систему инициализации) и изменений, делающих невозможным обновление существующих систем на новую версию eudev.
Для минимизации регрессивных изменений планируется поддерживать активную ветку разработки HEAD в состоянии постоянной готовности к релизу. Для того чтобы добиться высокого качества ветки HEAD добавление любого незначительного изменения потребует рецензирования со стороны другого разработчика eudev, для значительных изменений автору кода нужно будет получить рецензию от двух разработчиков. Кроме того, с целью упрощения поиска регрессий, коммиты, вносящие логически независимые изменения, должны явно документировать все затрагиваемые подсистемы.
Из задач, которые планируется решить на начальном этапе развития eudev упоминается работа по избавлению от привязки к особенностям новых версий ядра, возвращение возможности работы со старыми ядрами Linux и различными инструментариями, улучшение совместимости с существующими системами инициализации, такими как OpenRC и Upstart. В настоящее время уже выполнена переработка системы сборки и восстановлена поддержка некоторых старых ядер Linux до версии 2.6.31 включительно. Код помечен как готовый для выпуска первой бета-версии. В дерево портажей добавлен пакет eudev. Следующими шагами станет обеспечение поддержки библиотеки uclibc, устранение регрессий, вызванных переходом с module-init-tools на kmod, возвращение правил 70-persistent-net.rules и возможности использования отдельного раздела /usr без initramfs. В настоящее время проект systemd находится в процессе смены лицензии с GPL на LGPL, ответвление eudev произведено в разгар данного процесса и в дальнейшем разработчики форка намерены последовать примеру systemd и все развиваемые в рамках eudev улучшения распространять под лицензией LGPL.
В качестве примера неоправданной оптимизации в systemd-udevd, ведущей к регрессивным изменениям, упоминается переход на API kmod для загрузки модулей, который позволяет загружать модули ядра без вызова дополнительных утилит. Проблема такого подхода связана с тем, что kmod загружает модули последовательно, в то время как классическая обработка правил в udev производилась с ответвлением нового процесса. Экономия 0.01 мс на выполнение вызова fork() ничтожна по сравнению с задержкой в 10-20 мс, необходимой для загрузки данных с диска. Для ускорения загрузки модулей с диска в kmod планируется компоновать группу модулей в один файл, но данная возможность пока только в планах. Раньше, так как udev мог стартовать загрузку следующего модуля не дожидаясь окончания загрузки предыдущего, подобные задержки компенсировались параллельным чтением модулей. После перехода на API kmod все модули стали загружаться последовательно, и в случае зависания модуля, например, из-за невозможности инициализировать оборудование, теперь останавливается и загрузка других модулей. (Стоит отметить, что разработчики eudev упускают из виду то, что ядро Linux не поддерживает параллельную загрузку модулей — даже если одновременно запустить несколько процессов modprobe, запросы от них все равно будут поставлены в очередь и выполнены последовательно. Кроме того, использование libkmod позволяет не только избавиться от форка и запуска лишних процессов, но и избежать повторного выполнения таких операций как разбор файла конфигурации и загрузка индексов).
Что касается вопроса оптимизации скорости загрузки, то по мнению разработчиков eudev, при загрузке надёжность важнее скорости, а экономия микросекунд не оправдывает появление ошибок и урезание гибкости настройки, поэтому основное внимание будет уделяться в первую очередь устранению регрессивных изменений, внесённых разработчиками systemd. Тем не менее, разработчики eudev не отвергают предложений по ускорению загрузки, если такие предложения разумны, и намерены приступить к оптимизации скорости после выпуска нескольких стабильных релизов.
Источник: http://www.opennet.ru/opennews/art.shtml?num=35619
|
|
0 | Tweet | Нравится |
|
