Re: Каковы проблемы FreeBSD и пути их решения?
Ответ на пост от . В комментариях не умещается.
--
Вопросы по модульности охватывают не только систему портов. Взять пример, что firefox - не запускается без модуля sem (POSIX семофоры), кидает bad system call. Админ на то и админ, чтобы подправить, но это ж firefox - это уже десктоп. Этим вопросы к ядру не исчерпываются. Тем не менее пересборка ядра ведется и в монолитной основе, и с раскладкой по модулям.
Сами модули нельзя не вкомпилировать в ядро, поскольку без драйверов невозможна загрузка системы. Приходится одновременно поддерживать модули вкомпилируемуемые в систему (потом их не видно через kldstat), и в виде /boot/kernel файлов под FFS и ZFS - одновременно. Я бы предложил бы третий вариант, где модули лежали бы в архиве, пусть даже в zip или в tar, где были бы доступны в readonly режиме. По крайней мере так сразу видны имена пакетов (в отличии от ядра, собранного монолитом), и для zip - может выполняеться crc проверка. Чтобы скорость чтения архива была приемлемой, закешированные имена файлов могут указывать на смещения и копию контекста по распаковке.
Выбор пакета, с которого будет загружаться ОС, желательно вынести в меню. Понимаю, что ядра скомпилированные с поддержкой какой-то фичи, и без поддержки этой фичи - могут различаться координально (например набор для отладки от DEADLOCK блокировок). Однако как отлаживать, если именно на этой машине вдруг ни с того ни с сего пошли мертвые зависоны - собрать ядро на другой машине, и переслать на целевую? Можно. Или распаковать отладочное ядро которое возможно уже находится на том же диске (или указать его для загрузки). Я за второй вариант.
Но есть ли в ядре так много опций, про которые помнить - обязательно. Некоторые опции локализованны в одном-двух кусках кода - пересобирать весь мир становится смешно (речь не о макросах, и не о inline функциях - тут лучше предоставить свободу). Если речь идет про ассемблерные вставки для оптимизации в определенную функцию, то их бы реализовать через weak указатели. Ну или пожертвовать производительностью, и сделать функции переопределяемыми. Некоторые опции вообще лучше не отключать, иначе странным образом перестает все работать. Почему это тогда есть опция?
В начале был приведен пример про bad system call. Ядро, которое уже застартовано, не может себе позволить загрузить из файловой системы модуль автоматически (хотя бы потому, что оно уже может быть другой сборки, кстати - если это так, то грабли могут выскочить без предупреждения) - хотя вполне может знать, какого модуля ей не хватает. Тут бы не помешал вывод на консоль "приложение X хочет доступ к Y которое реализано в модуле Z. Сам не могу подгрузить, поэтому по человечески прошу - сделайте это для меня". Вообще, почему бы всему набору модулей не загрузиться в своп - он и так не сильно используется, а когда полностью используется - тогда крантец полный. По политикам интуитивности ядро само могло бы подгрузить недостающий модуль из свапа, и не дампать корки моего файрфокса зазря. Ведь я уже успел обматерить мазилу и иксы до того, как разобрался в чем дело.
Кстати, о вендорах. Набор модулей и устройств стремительно близится к бесконечности. Потому хочеться иногда включить - все, и пусть что потребляется мегабайты ОЗУ, зато какая-то из полезных вещей не забыла прогрузиться. В итоге в ядре болтается сразу несколько модулей, которые и рады были бы что-то сделать с железом, да только этого железа как-то нет пока. Такое впечатление, что соудбластер вдруг внезапно впаяют прям в работающее железо. Или процессоров вдруг станет десять. Или сетевой адаптер вышедший из слота вдруг станет на место. Мало ли чудес на свете бывает? Надо бы что-то с этим оптимизмом сделать. Но есть немалая вероятность что при перезагрузке объявится новое железо, или системы виртуализации позволят что-то с ним сделать. Не забывая про USB и Firewire, которые вообще существуют ради подключения на лету.
В качестве предложения: было бы неплохо сделать карту, которая каждому устройству определяла бы возможность работы без выгрузки, наследуемость этого флага от признаков родительского устройства, и возможность определения этого флага на этапе загрузки.
Еще пару слов о модульности. Можно было бы сделать несколько вариантов загрузки кернела:
- когда каждый модуль самостоятельно опрашивает имеющееся оборудование и по флагу решает, нужно ли ему завершить свою работу, если оборудование не нашлось (в порядке очереди, которую должна быть возможность переопределить, в качестве примера можно привести неоднозначность работы модулей pf и ipfw в зависимости от очереди прогрузки);
- по всем модулям составляется единная база данных устройств, и даже если под какое-то устройство попадает несколько драйверов, чтобы была возможность выбора из списка, какому следует загрузиться, если они взаимоисключают работу друг-друга.
Второй пункт возможен при наличии унифицированных данных, например по PCI шине. Наличие COM-порта уже нужно опрашивать самостоятельно. Наличие базы сделает ненужным загрузку модуля на постоянной основе - модуль может отсавить метки узнавания оборудования, и выгрузиться. Наличие этой базы как отдельной сущности может сделать возможным регистрацию в нем нового оборудования без перекомпиляции. То есть пользователь обладая возможностью администратора (например, посмотрев информацию через pciconf), уже может помочь сообществу пополнять базу устройств, которую потом можно будет и вкомпилировать в модуль. Хотя думаю что тенденция может измениться в сторону поддержки этой базы данных как отдельного списка, с дистрибуцией по сети, с реализацией инициализаций, уточнением фирмвейр и прочих воркараундов через llvm или какой-то простой ЯП.
Теперь пару слов об портах. Такие, как они есть, мне очень нравятся. Но мне кажется, что следует ревизию порта закладывать на обязательной основе в имя порта, чтобы зависимости не рушились в плоской модели, где каждый компонент был тестирован на совместимость с другим компонентом. Уход прогресса вперед очень приветствуется, но даже скорые поезда должны стоять достаточно времени, чтобы даже самые малоподвижные пассажиры имели возможность сесть на него и также сойти на необходимой остановке. Это также означает, что библиотеки должны иметь возможность уживаться со своими же более ранними релизами. Да, если в них обнаружен баг, то их нужно пересобрать. Но пересобирать каждый раз KDE из-за бага в libpng - десктопы этого не любят. Ubuntu, если бы выпустил обновление, после которого гном не запустился бы, сразу бы слил в своей базе множество пользователей.
Но с другой стороны, какие тут могут быть фиксы? Если ABI не поменялось, то все библиотеки .so с меньшим номером следовало бы заменить на символические ссылки обновленного собрата. Для большей уверенности, что в ABI только багфиксы и наращение функционала - требуется сверщик ABI. Для линковщиков желательно ведение лога, какие функции библиотек экспортируются для данного приложения еще на уровне компиляции, что помогло бы и с диагностикой безопасности приложений, для выработки рекомендаций на обновление. Но последнее уже на уровне фантазии, поскольку некоторые макросы могут скрыть часть реализации в заголовках файла, что создает значительные трудности диагностики.
--
Вопросы по модульности охватывают не только систему портов. Взять пример, что firefox - не запускается без модуля sem (POSIX семофоры), кидает bad system call. Админ на то и админ, чтобы подправить, но это ж firefox - это уже десктоп. Этим вопросы к ядру не исчерпываются. Тем не менее пересборка ядра ведется и в монолитной основе, и с раскладкой по модулям.
Сами модули нельзя не вкомпилировать в ядро, поскольку без драйверов невозможна загрузка системы. Приходится одновременно поддерживать модули вкомпилируемуемые в систему (потом их не видно через kldstat), и в виде /boot/kernel файлов под FFS и ZFS - одновременно. Я бы предложил бы третий вариант, где модули лежали бы в архиве, пусть даже в zip или в tar, где были бы доступны в readonly режиме. По крайней мере так сразу видны имена пакетов (в отличии от ядра, собранного монолитом), и для zip - может выполняеться crc проверка. Чтобы скорость чтения архива была приемлемой, закешированные имена файлов могут указывать на смещения и копию контекста по распаковке.
Выбор пакета, с которого будет загружаться ОС, желательно вынести в меню. Понимаю, что ядра скомпилированные с поддержкой какой-то фичи, и без поддержки этой фичи - могут различаться координально (например набор для отладки от DEADLOCK блокировок). Однако как отлаживать, если именно на этой машине вдруг ни с того ни с сего пошли мертвые зависоны - собрать ядро на другой машине, и переслать на целевую? Можно. Или распаковать отладочное ядро которое возможно уже находится на том же диске (или указать его для загрузки). Я за второй вариант.
Но есть ли в ядре так много опций, про которые помнить - обязательно. Некоторые опции локализованны в одном-двух кусках кода - пересобирать весь мир становится смешно (речь не о макросах, и не о inline функциях - тут лучше предоставить свободу). Если речь идет про ассемблерные вставки для оптимизации в определенную функцию, то их бы реализовать через weak указатели. Ну или пожертвовать производительностью, и сделать функции переопределяемыми. Некоторые опции вообще лучше не отключать, иначе странным образом перестает все работать. Почему это тогда есть опция?
В начале был приведен пример про bad system call. Ядро, которое уже застартовано, не может себе позволить загрузить из файловой системы модуль автоматически (хотя бы потому, что оно уже может быть другой сборки, кстати - если это так, то грабли могут выскочить без предупреждения) - хотя вполне может знать, какого модуля ей не хватает. Тут бы не помешал вывод на консоль "приложение X хочет доступ к Y которое реализано в модуле Z. Сам не могу подгрузить, поэтому по человечески прошу - сделайте это для меня". Вообще, почему бы всему набору модулей не загрузиться в своп - он и так не сильно используется, а когда полностью используется - тогда крантец полный. По политикам интуитивности ядро само могло бы подгрузить недостающий модуль из свапа, и не дампать корки моего файрфокса зазря. Ведь я уже успел обматерить мазилу и иксы до того, как разобрался в чем дело.
Кстати, о вендорах. Набор модулей и устройств стремительно близится к бесконечности. Потому хочеться иногда включить - все, и пусть что потребляется мегабайты ОЗУ, зато какая-то из полезных вещей не забыла прогрузиться. В итоге в ядре болтается сразу несколько модулей, которые и рады были бы что-то сделать с железом, да только этого железа как-то нет пока. Такое впечатление, что соудбластер вдруг внезапно впаяют прям в работающее железо. Или процессоров вдруг станет десять. Или сетевой адаптер вышедший из слота вдруг станет на место. Мало ли чудес на свете бывает? Надо бы что-то с этим оптимизмом сделать. Но есть немалая вероятность что при перезагрузке объявится новое железо, или системы виртуализации позволят что-то с ним сделать. Не забывая про USB и Firewire, которые вообще существуют ради подключения на лету.
В качестве предложения: было бы неплохо сделать карту, которая каждому устройству определяла бы возможность работы без выгрузки, наследуемость этого флага от признаков родительского устройства, и возможность определения этого флага на этапе загрузки.
Еще пару слов о модульности. Можно было бы сделать несколько вариантов загрузки кернела:
- когда каждый модуль самостоятельно опрашивает имеющееся оборудование и по флагу решает, нужно ли ему завершить свою работу, если оборудование не нашлось (в порядке очереди, которую должна быть возможность переопределить, в качестве примера можно привести неоднозначность работы модулей pf и ipfw в зависимости от очереди прогрузки);
- по всем модулям составляется единная база данных устройств, и даже если под какое-то устройство попадает несколько драйверов, чтобы была возможность выбора из списка, какому следует загрузиться, если они взаимоисключают работу друг-друга.
Второй пункт возможен при наличии унифицированных данных, например по PCI шине. Наличие COM-порта уже нужно опрашивать самостоятельно. Наличие базы сделает ненужным загрузку модуля на постоянной основе - модуль может отсавить метки узнавания оборудования, и выгрузиться. Наличие этой базы как отдельной сущности может сделать возможным регистрацию в нем нового оборудования без перекомпиляции. То есть пользователь обладая возможностью администратора (например, посмотрев информацию через pciconf), уже может помочь сообществу пополнять базу устройств, которую потом можно будет и вкомпилировать в модуль. Хотя думаю что тенденция может измениться в сторону поддержки этой базы данных как отдельного списка, с дистрибуцией по сети, с реализацией инициализаций, уточнением фирмвейр и прочих воркараундов через llvm или какой-то простой ЯП.
Теперь пару слов об портах. Такие, как они есть, мне очень нравятся. Но мне кажется, что следует ревизию порта закладывать на обязательной основе в имя порта, чтобы зависимости не рушились в плоской модели, где каждый компонент был тестирован на совместимость с другим компонентом. Уход прогресса вперед очень приветствуется, но даже скорые поезда должны стоять достаточно времени, чтобы даже самые малоподвижные пассажиры имели возможность сесть на него и также сойти на необходимой остановке. Это также означает, что библиотеки должны иметь возможность уживаться со своими же более ранними релизами. Да, если в них обнаружен баг, то их нужно пересобрать. Но пересобирать каждый раз KDE из-за бага в libpng - десктопы этого не любят. Ubuntu, если бы выпустил обновление, после которого гном не запустился бы, сразу бы слил в своей базе множество пользователей.
Но с другой стороны, какие тут могут быть фиксы? Если ABI не поменялось, то все библиотеки .so с меньшим номером следовало бы заменить на символические ссылки обновленного собрата. Для большей уверенности, что в ABI только багфиксы и наращение функционала - требуется сверщик ABI. Для линковщиков желательно ведение лога, какие функции библиотек экспортируются для данного приложения еще на уровне компиляции, что помогло бы и с диагностикой безопасности приложений, для выработки рекомендаций на обновление. Но последнее уже на уровне фантазии, поскольку некоторые макросы могут скрыть часть реализации в заголовках файла, что создает значительные трудности диагностики.