Внешним модулям ядра необходимо тестирование, которое не может произойти в хешере под юзером, поэтому есть идея создавать тестовое окружение в initrd и запускать его через qemu. Для этого в make-initrd не хватает или не удобно сделано: - Необходима возможность запуска make-initrd под юзером (скажем при опции --no-checks). Сейчас приходится подменять id на echo 0. (Пермишены на чтение /boot и /lib/modules будут сделаны rpm-build-kernel-perms хелпером, depmod отключен --no-depmod.) - Необходима возможность добавлять внешние модули в initrd, находящиеся в произвольных дирах. Сейчас приходится класть модуль в /usr/src/mod/ и в confik.mk писать KERNEL_MODULES = /usr/src/mod MODULES_ADD += xt_so.ko тогда make-initrd находит, что у xt_so.ko есть зависимость x_tables и добавляет его. Однако, всё равно внутри initrd нельзя загрузить модуль так как там нет insmod, а modules.* не содержит упоминаний для xt_so.ko. Поэтому нельзя использовать modprobe. Я ещё даже не придумал как это решить. Я думал над вариантом сделать user readable/writabe копию /lib/modules (скажем в /usr/srs/lib/), но make-initrd не поддерживает смену basedir. - Неудобно, что depinfo требуются modules.*.bin для работы, приходится вставлять их генерацию в хелпер. - PUT_DIRS добавляет диру стрипая префикс, а PUT_FILES оставляя, было бы удобнее, чтоб можно было указать в какое место initrd класть диру/файл. Хочется положить бинарник модуля не в произвольную диру, а в /lib/modules/*/misc (или extra/). - Нельзя положить в iproute2's бинарник ip через PUT_PROGS, его перекрывает busybox. (Он нужен чтоб сделать "сеть" через veth.) - PUT_PROGS не может полностью добавить бинарник iptables так как не видит, что ему требуется /lib*/iptables/. Впрочем, это можно пофиксить через PUT_FILES += /lib*/iptables/*.so - Не помешала бы feature запускающая фиксированный скрипт (точка входа в тесты) и после этого делающая shutdown системе, без таймаутов и прочего.
(В ответ на комментарий №0) > Внешним модулям ядра необходимо тестирование, которое не может произойти в > хешере под юзером, поэтому есть идея создавать тестовое окружение в initrd и > запускать его через qemu. > > Для этого в make-initrd не хватает или не удобно сделано: > > - Необходима возможность запуска make-initrd под юзером (скажем при опции > --no-checks). Сейчас приходится подменять id на echo 0. (Пермишены на чтение > /boot и /lib/modules будут сделаны rpm-build-kernel-perms хелпером, depmod > отключен --no-depmod.) Ок. Это можно сделать. > - Необходима возможность добавлять внешние модули в initrd, находящиеся в > произвольных дирах. Сейчас приходится класть модуль в /usr/src/mod/ и в > confik.mk писать > > KERNEL_MODULES = /usr/src/mod > MODULES_ADD += xt_so.ko > > тогда make-initrd находит, что у xt_so.ko есть зависимость x_tables и добавляет > его. Однако, всё равно внутри initrd нельзя загрузить модуль так как там нет > insmod, а modules.* не содержит упоминаний для xt_so.ko. Поэтому нельзя > использовать modprobe. Я ещё даже не придумал как это решить. Потому что depmod создаёт их только в /lib/modules/KVERSION. Позтому нет смысла менять путь в initrd. > Я думал над вариантом сделать user readable/writabe копию /lib/modules (скажем > в /usr/srs/lib/), но make-initrd не поддерживает смену basedir. Сделайте /lib/modules user writabe. > - Неудобно, что depinfo требуются modules.*.bin для работы, приходится > вставлять их генерацию в хелпер. Он использует libkmod. Это libkmod их использует. > - PUT_DIRS добавляет диру стрипая префикс, а PUT_FILES оставляя, было бы > удобнее, чтоб можно было указать в какое место initrd класть диру/файл. Хочется > положить бинарник модуля не в произвольную диру, а в /lib/modules/*/misc (или > extra/). PUT_DIRS/PUT_FILES -- это хэлперы у которых есть определённый сюзкейс. Они нужны, чтобы просто добавлять файлы в образ. Для более сложных случаев они не подходят. Придумывать язык в этом месте будет неправильно. Если хочется что-то положить под другим именем, то это можно сделать в соответствующей цели без врапперов. > - Нельзя положить в iproute2's бинарник ip через PUT_PROGS, его перекрывает > busybox. (Он нужен чтоб сделать "сеть" через veth.) Да, так было задумано. Раньше это не мешало. Как быстрое решение ip можно положить в другой каталог. > - PUT_PROGS не может полностью добавить бинарник iptables так как не видит, что > ему требуется /lib*/iptables/. Впрочем, это можно пофиксить через PUT_FILES += > /lib*/iptables/*.so Это так и должно быть. Такие вещи на совести кладущего что-то в образ. > - Не помешала бы feature запускающая фиксированный скрипт (точка входа в тесты) > и после этого делающая shutdown системе, без таймаутов и прочего. Положите в образ /sbin/init-bin с своим содержимым и этот файл заменит init в образе. Этим пользуется make-initrd-propagator.
Спасибо за ответ. (В ответ на комментарий №1) > > - Не помешала бы feature запускающая фиксированный скрипт (точка входа в тесты) > > и после этого делающая shutdown системе, без таймаутов и прочего. > > Положите в образ /sbin/init-bin с своим содержимым и этот файл заменит init в > образе. Этим пользуется make-initrd-propagator. Ок, но oneshot feature была бы предпочтительнее, чтоб не делать работу init самому (держать такой ALT-specific скрипт инициализации в upstream мало смысла). Хотя, может так и лучше.
(В ответ на комментарий №2) > > Положите в образ /sbin/init-bin с своим содержимым и этот файл заменит init в > > образе. Этим пользуется make-initrd-propagator. > > Ок, но oneshot feature была бы предпочтительнее, чтоб не делать работу init > самому (держать такой ALT-specific скрипт инициализации в upstream мало > смысла). Хотя, может так и лучше. Файл /sbin/init-bin не ALT-specific. Недавно это было настоящим init'ом и частью системы инициализации, а модуль make-initrd-propagator это заабьюзил, чтобы подменить init на себя. Я не хотел такого, но раз уж так случилось, то пусть уж используется.
При тестирования использую вот такую фичу/хак: /people/legion/packages/make-initrd-hacker.git для установленных в систему ядер. Для апстримных ядер и тестирования патчей к нему это несовсем подходит и я использую другой инструмент. Для этой фичи я использую скрипт: $ cat ./run-unfsd /usr/sbin/unfsd -e "$cwd/exports" -d -n 9000 -m 9001 -p $ cat "$cwd/exports" / 127.0.0.1(rw,insecure)
(In reply to comment #4) > При тестирования использую вот такую фичу/хак: Спасибо! ps. Пытались заюзать 9p virtfs qemu, для того, чтоб загрузить "полную" систему из того что установлено в хешере (идея glebfm). Не вышло, так как при security_model=mapped-file - не работают симлинки, а без - всё равно не хватает пермишенов. Буду ещё думать на эту тему, чтоб расширить возможности тестирования в хешере под реальным рутом.
(В ответ на комментарий №5) > (In reply to comment #4) > > При тестирования использую вот такую фичу/хак: > > Спасибо! > > ps. Пытались заюзать 9p virtfs qemu, для того, чтоб загрузить "полную" систему > из того что установлено в хешере (идея glebfm). Не вышло, так как при > security_model=mapped-file - не работают симлинки, а без - всё равно не хватает > пермишенов. Буду ещё думать на эту тему, чтоб расширить возможности > тестирования в хешере под реальным рутом. Для разработки ядра использую 9p и qemu, но без хэшера. Я сделал корманный враппер для Кирилла Шутемова: https://github.com/legionus/vm Он позволяет запускать ядро из дерева исходников с доступом к хостовой файловой системе откуда я запускаю тесты. Собственно make-initrd-hacher делает тоже самое, но на nfs, а vm у меня остался как запускалка тестов.
То что я обещал сделать вроде уже сделано и в сизифе.
