Обычной практикой является предоставление драйверов ядра Linux (объекты ядра KOs) в исходном коде, их сборка и установка на целевой компьютер. Например, драйверы дисплея Nvidia, драйверы дополнительных модулей Oracle VirtualBox устанавливаются таким образом. Также обычным делом является получение новой версии ядра (с соответствующими заголовками) через обновление системы. Для этого необходимо перестроить и переустановить KO, в противном случае устройство перестанет работать после обновления.
В нашем сценарии запуска установки продукта мы хотим добавить шаг для создания и установки KO при каждой загрузке. Пользователь может отказаться от участия, и ему придется вручную собрать и установить KO. Драйвер устройства обменивается данными с USB-устройством. Соответствующие подробности: 1. Фактическое пересборка произойдет только один раз при установке нового ядра, потому что make не будет пытаться пересобрать файл, который уже существует и является актуальным. 2. Пересборка драйвера занимает около 2 секунд и миллисекунды, чтобы пропустить сборку во время нормальной загрузки (не после обновления ядра). 3. В маловероятном случае сбоя сборки не должно происходить сбоя системы или ее нестабильности. однако наше аппаратное устройство работать не будет. 4. Некоторые дистрибутивы могут позволять регистрировать хуки, выполнять действия с определенными событиями, например, обновление ядра. Однако мы пытаемся реализовать что-то, что единообразно будет работать с большинством дистрибутивов. Наш установщик - это скрипт + tar или скрипт + rpm. К сожалению, в этом выпуске у нас нет пропускной способности для подготовки собственных пакетов для всех дистрибутивов (например, в стиле debian).
Вопросы: 1. Это приемлемое решение? Если нет, то почему? 2. Каковы потенциальные риски, связанные с этим подходом? 3. Какое правильное / предпочтительное место для запуска make при запуске? rc.local или скрипт под init.d или другое? Цель состоит в том, чтобы заставить его работать с большинством дистрибутивов, используя один и тот же метод (если это вообще возможно).
Это будет зависеть от вашего оборудования.
Если вы это сделаете, будьте абсолютно уверены, что время ожидания вашего скрипта истечет через несколько секунд, в противном случае у вас, вероятно, будет много администраторов, которые задаются вопросом, почему какая-то машина в объекте размещения на другом конце страны не вернулась. после обновления ядра.
Если ваше оборудование критически важно для процесса загрузки (например, сетевой ключ или USB-накопитель), то это нужно будет сделать раньше (возможно, перед новое ядро загружается). В противном случае вам нужно было бы сделать это как можно позже, чтобы убедиться, что все подключенные к сети файловые системы, которые могут потребоваться для компилятора, на месте. Это также поможет убедиться, что MTA запущен, чтобы ваш процесс сборки мог отправить root электронное письмо, если модуль по какой-то причине не может быть собран.
1) Да, но вы должны добавить четкое описание того, как мы можем запустить ваш скрипт вручную, чтобы мы могли убедиться, что скрипт вернется нормально. В случае виртуального бокса в centos они добавляют скрипт в /etc/init.d под названием vboxdrv
Использование: /etc/init.d/vboxdrv {start | stop | stop_vms | restart | force-reload | status | setup}
Это ясно, мы можем запустить / остановить сценарий и получить его статус, поэтому риск возникновения проблем при перезагрузке минимален, если мы можем проверить сценарий на новом ядре перед его развертыванием. Вы не можете иметь более стандартного, чем этот, для меня это идеально.
2) систематический сбой процесса компиляции и отсутствие доступного модуля. Это трагично? Я так не думаю. Пока ваш скрипт не вешает машину и вы даете полный журнал сбоя компиляции в / var / log / mymodule, вы не можете добиться большего.
3) см. 1) В centos / RHEL / fedora) vboxdrv запускается из /etc/init.d/vboxdrv и проверяет имя дистрибутива, а затем создает соответствующие сценарии. /etc/init.d - это первое место, которое я проверяю, когда мне нужна дополнительная информация о демоне. Меня это устраивает.
Поддержка модуля динамического ядра (DKMS), подробно здесь, позволяет предварительно собрать драйвер перед ты перезагружаешься. В Linux Journal есть статья "Изучение DKMS"в котором подробно рассказывается о том, как использовать и настраивать DKMS.
Если вы сможете выполнить восстановление до перезагрузки, ваша уверенность возрастет в том, что перезагрузка произойдет правильно и быстро.