| 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 задействована |