Pull to refresh

Comments 8

Мало того, что под каждое ядро нужна сборка модуля, уже в процессе использования он может «протухнуть». Было принято решение добавить его пересборку перед каждым запуском userspace приложения.

Почему не штатный DKMS, который будет пересобирать модуль при обновлениях ядра?

Здравствуйте! Даже без обновления ядра, при изменении окружения и прочего, система говорила, что модуль не валиден.

Без технических подробностей мне нечего подсказать. Модули просто так не "протухают в процессе использования".


Пересборка в сервисе — опасный костыль. Например, DKMS версионирует модули и при установке копирует исходники и бинарник модуля в папку конкретного ядра, чтобы при откате обновления получить то же ядро с теми же версиями модулей. Или у вас можно обновить ядро при выключенном сервисе и только потом обнаружить, что он не может собрать модуль. Каталог с исходниками придется защищать от изменений. Изменяемый бинарный код плохо сочетается с подписью, аудитом, сертификацией.

Здравствуйте! Спасибо за комментарий, действительно пересборка перед запуском демона не является штатным механизмом, но она защищает нас от большинства ошибок при работе. Предложенное решение является лишь одним из вариантов, позволивший решить задачу, и в нашем случае — достаточным.
Здравствуйте! Inotify — отличный инструмент для мониторинга в ФС, но не подошел из-за того, что он логирует события уже после того, как они произошли. Для нашего же продукта необходима реакция в момент совершения события. Перехват можно обработать при помощи fanotify. Нам он не подошёл, из-за того, что отсутствовала возможность обработки событий удаления, переименования, перемещения.
Спасибо большое за ответ и статью! Сам недавно занимался созданием мониторинга файлов, и найти комплексно собранную информацию по этому вопросу как в вашей статье, мне не удалось.
Спасибо, за тёплые слова, всегда рад помочь.
Sign up to leave a comment.