Добавить в etercifs при упаковке в пакет проверку сборки для всех ядер, для которых есть установленные хедеры.
Только нужно чётко осознать критерии проверки каталога на возможность сборки модуля ядра... Я бы предожил проверять по наличию Make-файла, в котором заданы VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = Y и, например файла 'include/linux/version.h'
Я бы предложил посмотреть, как было сделано в linux-cifs, поэтому что все эти проверки уже были сделаны и отлажены. Всё иное - это трата времени ещё раз.
Сегодня занимался этим вопросом. Переработал полностью скрипты buildmodule.sh и function.sh с дополнительной целью сделать код более прозрачным и минимизировать повтор кода. Добавил кусок из старого build.sh, который и определяет KERNELVERSION по адресу исходника kernel-modules. Много кода вынес в functions.sh При рассмотрении скрипта выяснилось, что в случае обычной сборки модуля я уже не пользуюсь переменной BASE_KERNEL_SOURCES_DIR, которая берётся из файла kernel_src.list, а вычисляю сперва [ -n "$KERNELVERSION" ] || KERNELVERSION=`uname -r` а затем KERNSRC=/lib/modules/$KERNELVERSION/build Я на радостях избавился от kernel_src.list, а заодно и от иаскания за собой скрипта distr_vendor. Поскольку было уже много сборок под разные дистры, это дает мне возможность предполагать, что ссылка /lib/modules/$KERNELVERSION/build, указующая на хедера исходников для модулей везде одинакова. Пробегать по хедерам можно так: [ -n "$KERNEL_SRC_LIST" ] || KERNEL_SRC_LIST=`readlink /lib/modules/*/build` for KERNSRC in $KERNEL_SRC_LIST ; do ... И в этом случае без всяких проверок мы получаем то, что нужно. Далее, я сделал дополнительный параметр для сервиса etercifs: service etercifs testbuild выглядит его запуск так: TESTBUILD=1 sh buildmodule.sh То есть просто добавился параметр, в зависимости от значения которого либо собирается модуль ядра, либо проверяется сборка для всех найденных ядер. Во втором случае результатом работы скрипта будет несколько сообщений в консоль о результатах проверки. Далее я стал добиваться того, чтобы скрипт запускался в спеке при создании rpm. Все бы ничего, да нет прав на просмотр папки /lib/modules. В итоге опять вернулся к старым костылям (в спеке): KERNEL_SRC_LIST=/usr/src/* TESTBUILD=1 ETERCIFS_SOURCES_LIST=sources/kernel-source-etercifs* sh ./buildmodule.sh А для общности придется козвращать kernel_src.list и distr_vendor, если мы хотим довести это дело до логического завершения. Есть и ещё один довод в пользу того, чтобы все же не делать сборку при создании rpm - раньше скрипт предназначался не для проверки сборки, а для сборки модуля, поэтому, если что-то обламывалось, то и сборка обламывалась. Например, я для проверки поставил сборочную зависимость на все имеющиеся в Сизифе kernel-headers-modules* и в одном случае (led-tc) сборка не нашла хедеры и в итоге rpm не собралось. Теперь, чтобы исключить это надо по всему коду проверки ставить и тестировать разные случаи, способные помешать сборке модуля. Я полагаю, что добавления команды service etercifs testbuild может и хватить для решения задачи быстрой проверки собираемости модуля для системы для всевозможных хедеров. При этом мы избавляемся от костылей с разными путями к исходникам и не волнуемся, что у нас какой-то хедер сорвет сборку rpm. Получается более "красивое" и "устойчивое" решение. Пакет я пока не сделал, Коды в гит http://git.etersoft.ru/people/kipruss/packages/etercifs.git Версия будет 3.7.0 с каким-то не первым релизом, поскольку изменения в скриптах и поскольку alt1 уже случился. Жду критику и указания. Также напишу сюда и продублирую в devel ещё одну не очень приятную информацию касающуюся сборки etercifs При тестировании при помощи RECT поведения драйвера при установке блокировок DENY обнаружилось, что при одних и тех же версиях RECT и etercifs, но на разных релизах ядра - 2.6.25-std-def-alt9 и 2.6.25-std-def-alt10 мы наблюдаем различное поведение тестов. А именно в ядре alt9 тесты просто не работали. Вывод очевиден: в новом etercifs появились куски кода из ветки ядра 2.6.25.19, в том числе и новая функция, я ядро alt9, по всей вероятности, ещё не содержало этих изменений. В итоге драйвер собирается, но работает не вполне так, как бы нам того хотелось. Я думаю, что такая ситуация не очень часто будет встречаться, но факт налицо. В итоге надо как-то выходить из положения, возможно, нужно создать ещё веток для каждого изменения минорный версий ядер, возможно ещё что-то. Или просто решать вопросы по мере их поступления (под конкретные ядра в дистрибутивах). Я пока не могу придумать красивого выхода из этой ситуации кроме полного пропихивания в ядро всего, что нам надо от CIFS и прекращения всего этого зоопарка в дальнейшем.
(In reply to comment #3) > Пробегать по хедерам можно так: > > [ -n "$KERNEL_SRC_LIST" ] || KERNEL_SRC_LIST=`readlink /lib/modules/*/build` > for KERNSRC in $KERNEL_SRC_LIST ; do > ... Выяснилось, что такой код не всегда работает. Предлагаю другой, который работает: for LM in `ls /lib/modules` ; do KERNSRC=`readlink /lib/modules/$LM/build` if [ $KERNSRC ] ; then [ -L $KERNSRC ] && continue [ -f $KERNSRC/.config ] || continue здесь код проверочных сборок модуля fi done Проверки возможно избыточны, но на всякий случай пусть будут. Ещё одну оторвал. Таким образом переменная KERNSRC становится только внутренней и для сборки модуля не под текущее ядро надо указывать только KERNELVERSION, например так: KERNELVERSION=2.6.25-std-def-alt8.M41.1 service etercifs build Надо будет поправить документацию. Фразу: При вызове build можно указать путь к заголовочным файлам ядра для сборки: KRNSRC=/usr/src/путь service etercifs build. Или только версию ядра: KERNELVERSION=2.6.26-std-pae /etc/init.d/etercifs build. Предлагаю изменить на: При вызове build можно указать версию ядра, отличного от текущего, для которого требуется собрать модуль (для него должны быть установлены заголовочные файлы ядра): KERNELVERSION=2.6.26-wks-smp-alt1 /etc/init.d/etercifs build. Пояснение: Только KERNSRC без KERNELVERSION указать нельзя, потому что если не указать KERNELVERSION, он возьмется из текущего ядра. И без указания KERNSRC нельзя просто написать KERNELVERSION=2.6.26-wks-smp, надо указать ещё и релиз, т.е. KERNELVERSION=2.6.26-wks-smp-alt1. Это связано с тем, что если не указано KERNSRC, то KERNSRC=/lib/modules/$KERNELVERSION/build и $KERNELVERSION в данном случае должна иметь формат такой же, как вывод uname -r для данной системы. Можно, конечно, указать обе переменные типа: KERNSRC=/usr/src/linux-2.6.26-wks-smp KERNELVERSION=2.6.26-wks-smp service etercifs build И в таком случае не указывать релиз. Но это как-то по-моему неудобно и только запутает пользователя. Да и должен же человек осознавать для какого именно релиза ядра он модуль собирает! Кстати, в этой фразе есть неточность - переменная указана вместо KERNSRC - KRNSRC, так что все равно править. ====== 5-го числа соберу релиз, который должен закрыть эту багу (с моей точки зрения) и багу 2783. А 2804 в случае закрытия 2783 не будет иметь смысла, соответственно тоже закроется.
(In reply to comment #4) > > 5-го числа соберу релиз, который должен > закрыть эту багу (с моей точки зрения) и > багу 2783. А 2804 в случае закрытия 2783 не будет > иметь смысла, соответственно тоже > закроется. > В etercifs-3.7.0-alt2 добавлена команда service etercifs testbuild которая проверяет собираемости модудя под все установленные хедеры.