Bug 2782

Только нужно чётко осознать критерии проверки каталога на возможность сборки модуля ядра... Я бы предожил проверять по наличию 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

которая проверяет собираемости модудя под все установленные хедеры.