Summary: | Кросс-пересборка модулей под другую версию ядра | ||
---|---|---|---|
Product: | CIFS@Etersoft | Reporter: | megov <megov> |
Component: | упаковка, сборка, интеграция | Assignee: | BUGS@Etersoft <bugs> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | enhancement | ||
Priority: | P5 | CC: | kondratyuk, lav, megov |
Version: | не указана | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Whiteboard: | |||
Заявки RT: | Связано с: | ||
Дата напоминания: | |||
Bug Depends on: | |||
Bug Blocks: | 777 |
Description
megov
2008-01-20 15:09:48 MSK
Укажите пожалуйста пример команд, как вы собираетесь пользоваться вводимой переменной KERNELVERSION и кто её будет определять. Кстати, у нас есть обработка KERNSRC, позволяющая указать путь к исходникам. В приложенных патчах на build.sh и buildmodule.sh если не установлена $KERNELVERSION то версия определяется вызовом uname - это текущее поведение и оно остается таким по умолчанию. Однако можно переопределть $KERNELVERSION. В примерах патчей на linux-cifs и haspd переопределение выполняется анализом имени файла /boot/vmlinuz-*. Это было написано на скорую руку и не очень правильно и корректно в случае наличия нескольких ядер. Можно доработать build.sh и buildmodule.sh так, чтобы они принимали необязательный аргумент версии ядра и не использовали $KERNELVERSION. Т.е. фактически надо добавить опциональный параметр версии ядра к вызову service [haspd | linux-cifs] build в инит-скриптах. Кто и как будет добавлять этот параметр - вопрос отдельный, у меня например он будет вызываться из kickstart скрипта, который уже знает версию рабочего ядра, устанавливаемую на машину. Возможно нужно двигаться в сторону использования dkms? У нас есть пакеты для dkms. В новых версиях KERNELVERSION задействована |