LINUX.ORG.RU

Запуск модулей ядра в qemu

 , ,


0

1

Интересует ваш рабочий процесс запуска и отладки модулей ядра с использованием qemu.

Задача состоит в том, чтобы в генте настроить минимальное окружение для запуска и отладки модулей ядра. Под словом «минимальное» подразумевается значительно более легкая среда, чем отдельная выделенная конкретно для целей разработки виртуальная машина.

Что уже получается на данный момент:

1. Были собраны initramfs и ядро.

2. Собранное ядро успешно запускается следующей командой:

qemu-system-x86_64 \
    -append "console=ttyS0" \
    -enable-kvm \
    -initrd path/to/initramfs.gz \
    -kernel path/to/bzImage \
    -nographic \

В некоторых мануалах к этому ещё добавляются следующие опции:

-net nic,model=rtl8139
-net user
-net dump

Вопрос 1: в основном все найденные мануалы описывают процесс именно до этого момента. Минималистичное ядро загружено, ура, как будто на этом всё и закончилось. Далее подключаются с помощью внешнего отладчика.

Но мне необходимо вставить модуль. Какой обычно рабочий процесс (воркфлоу) у разработчиков модулей в данном случае (хотя бы вкрадце: ссылки, ключевые слова)?

Какой командой вы запускаете qemu и что делаете дальше?

jollheef, вот здесь ты писал, что запускаешь с помощью qemu. Буду признателен за комментарии.

Вопрос 2: предварительное изучение этого вопроса показало, что существуют ещё и другие подходы к разработке:

  • система: использовать просто ядро рабочей машины/отдельную физическую машину/ полноценные виртуальные машины / qemu / etc.;
  • диск: qemu-img / nfs / бездисковая загрузка / etc.;
  • вывод: qemu monitor / консоль / virt-manager;

Как лично вы это делаете?

Deleted

Последнее исправление: Deleted (всего исправлений: 3)

kvmtool + 9pfs

anonymous
()
Ответ на: комментарий от anonymous

Приведенная выше команда - это не фрагмент, а именно конечный (на данный момент) вариант. Т.е. пока отсутствует сеть, и отсутствует диск. А значит, как «на реальной машине» пока не получится. Я хочу понять, как мне обойтись чем-то значительно меньшим, чем виртуальная машина с полноценной системой. Например, ядра, работающие с qemu, могут быть собраны с make allnoconfig с совсем небольшими дополнениями.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Я хочу понять, как мне обойтись чем-то значительно меньшим, чем виртуальная машина с полноценной системой

Но зачем? Виртуальная машина с минимальной, но полноценной системой - это именно то, что нужно на практике.

Как лично вы это делаете?

Мы лично стандартными средствами делаем образ с минимальной системой. Если перед тобой не стоит задача отладки начального раскрутки или самообразования, любые другие решения - бессмысленная трата времени.

tailgunner ★★★★★
()

jollheef, вот здесь ты писал, что запускаешь с помощью qemu. Буду признателен за комментарии.

В одном терминале запущен qemu с нужным ядром (точно так же как и ты пишешь — qemu -kernel, console=ttyS0 и так далее), в другом делаю make qemu-insmod, внутри что-то вроде scp ${1} testhost: && ssh testhost insmod $(basename ${1}). На деле это чаще make qemu-test, где после insmod еще отрабатывают тесты.

Итогом лог сборки и тестов с одной стороны, трейс модуля ядра с другой. Отладчиком для разработки модулей ядра ползуюсь редко.

Образ для qemu делаю с помощью debootstrap (в основном дереве он есть).

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от Deleted

Я хочу понять, как мне обойтись чем-то значительно меньшим, чем виртуальная машина с полноценной системой.

debootstrap тебе выдаст стартовые скрипты и основные утилиты, засунь его в созданный qemu-img create blablabla образ. Ядро и initrd указываются в параметрах qemu.

Сделать еще меньше можно, например собирать initrd с твоим модулем ядра, но применения «в поле» особо нет такому — лишний геморрой.

Например, ядра, работающие с qemu, могут быть собраны с make allnoconfig с совсем небольшими дополнениями.

Я обычно make defconfig использую — в qemu работает. При правке кода непосредственно ядра пересборка в любом случае будет занимать копеечное время, ибо (если ты не правишь заголовочные файлы) пересоберется твой сишный файл и перелинкуется — там делов на 15 секунд.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Спасибо за развернутый ответ.

Я ещё рассматривал вариант, чтобы посредством virt-install кикстартом ставить виртуалки, скажем, Fedora/CentOS, при этом автоматически подключая в них шару NFS с кодом модулей, компиляторами и ядрами (чтобы не перебрасывать модуль с помощью scp, хотя ряд мануалов тоже использует scp). Это уже не минималистичный вариант, конечно.

В чем принципиальная разница запуска с qemu-system-x86_64 по сравнению с использованием виртуалок libvirt + qemu, запускаемых через virsh и установленных посредством virt-install? В том, что в случае с qemu-system-x86_64 будет удобнее и быстрее выбирать нужную версию загружаемого ядра? Или виртуализация будет уже какая-то другая?

Deleted
()
Последнее исправление: Deleted (всего исправлений: 3)
Ответ на: комментарий от Deleted

В чем принципиальная разница запуска с qemu-system-x86_64 по сравнению с использованием виртуалок libvirt + qemu, запускаемых через virsh и установленных посредством virt-install?

Если через virsh можно запускать так, чтобы на stdout был вывод лога ядра, то принципиальной разницы никакой.

В том, что в случае с qemu-system-x86_64 будет удобнее и быстрее выбирать нужную версию загружаемого ядра?

Да, я qemu-system использую по причине того, что просто указывать нужное ядро/initrd, и оно сразу с ним загрузится. libvirt, как мне кажется, не особо подходит под эту задачу.

Deleted
()
Ответ на: комментарий от Deleted

Это уже не минималистичный вариант, конечно.

Если уж так не хочется scp, то сделайте не initrd.gz, а реальный маленький диск в виде raw-файла, без сжатия, разбивать на партишены не надо, сразу делайте там файловую систему и монтируйте, модули можно так класть, если виртуалка монтирует как RO, или перед старом виртуалки размонтируете.

В чем принципиальная разница запуска с qemu-system-x86_64 по сравнению с использованием виртуалок libvirt + qemu

Второе удобнее, когда у вас целая ферма виртуалок в продакшене.

vodz ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.