Configuração do ambiente de teste do Linux Device Drivers

Question

Qual é a melhor maneira de configurar um ambiente de teste enquanto trabalha com Drivers de dispositivos Linux ?

Eu compilei um bzImage para x86 da fonte Linux mais recente usando x86_64_defconfig.

Eu segui o tutorial initramfs personalizado do Gentoo para que eu inicie um sistema de arquivos isolado baseado no Busybox. Eu uso exatamente o mesmo arquivo init que eles usam. A única diferença entre o que estou fazendo e o que eles fazem é que estou rodando no Ubuntu e baixando o último binário Busybox x86_64 ao invés de usar o emerge.

No meu sistema Ubuntu 16.04, estou executando

qemu-system-x86_64 -kernel arch/x86/boot/bzImage -append "console=ttyS0" -initrd custom-initramfs.cpio.gz -nographic

onde custom-initramfs.cpio.gz refere-se ao initramfs que eu construí e compactei como no tutorial do Gentoo.

Eu corri tudo isso e ainda acabo com um erro no kernel, como visto abaixo

[    2.893799] md: Waiting for all devices to be available before autodetect
[    2.894724] md: If you don't use raid, use raid=noautodetect
[    2.913768] md: Autodetecting RAID arrays.
[    2.914465] md: Scanned 0 and added 0 devices.
[    2.914879] md: autorun ...
[    2.915478] md: ... autorun DONE.
[    2.920719] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[    2.921465] Please append a correct "root=" boot option; here are the available partitions:
[    2.922493] 0b00         1048575 sr0  driver: sr
[    2.923069] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    2.923101] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc1+ #18
[    2.923101] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[    2.923101]  0000000000000000 ffff8800070ffde0 ffffffff81328158 ffff8800066aa000
[    2.923101]  ffffffff81b98e58 ffff8800070ffe60 ffffffff81124120 0000000000000010
[    2.923101]  ffff8800070ffe70 ffff8800070ffe08 ffffffff8112441e ffff8800070ffe78
[    2.923101] Call Trace:
[    2.923101]  [<ffffffff81328158>] dump_stack+0x4d/0x65
[    2.923101]  [<ffffffff81124120>] panic+0xca/0x1fc
[    2.923101]  [<ffffffff8112441e>] ? printk+0x43/0x4b
[    2.923101]  [<ffffffff81f4a364>] mount_block_root+0x175/0x229
[    2.923101]  [<ffffffff81f4a519>] mount_root+0x101/0x10a
[    2.923101]  [<ffffffff81f4a653>] prepare_namespace+0x131/0x169
[    2.923101]  [<ffffffff81f4a03c>] kernel_init_freeable+0x1c0/0x1d5
[    2.923101]  [<ffffffff818e7669>] kernel_init+0x9/0x100
[    2.923101]  [<ffffffff818ed30f>] ret_from_fork+0x1f/0x40
[    2.923101]  [<ffffffff818e7660>] ? rest_init+0x80/0x80
[    2.923101] Kernel Offset: disabled
[    2.923101] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Eu posso inicializar no initramfs durante a inicialização local e não usando o QEMU. Esta opção de menu grub funciona

menuentry 'linux latest' {
    linux /boot/bzImage-latest
    initrd /boot/custom-initramfs.cpio.gz
}

em que bzImage e initramfs referem-se à mesma imagem padrão do kernel de configuração x86_64 e ao initramfs customizado antes.

O problema parece resultar do fato de o QEMU não ter o mesmo acesso aos dispositivos em /dev que a máquina local faz.

O que posso consertar para que isso funcione em um ambiente QEMU? Meu objetivo aqui é apenas conseguir passar pela inicialização do kernel e em algum tipo de sistema de arquivos mínimo.

Acabei de criar meu primeiro patch de driver de dispositivo no trabalho, o que foi emocionante e quero continuar aprendendo mais. Qualquer ajuda seria apreciada!

    

Answer 1

Hacker do kernel autodidata aqui (e ainda mantém uma pequena parte dele).

Talvez não seja uma resposta definitiva, mas em primeiro lugar recomendo usar uma pequena placa incorporada como um framboesa pi, pois durante o desenvolvimento do kernel você precisará usar o hardware físico mais cedo ou mais tarde - emulação de software e VMs Não use os mesmos drivers e código que o hardware físico, ou adicione camadas extras de complexidade quando estiver tentando descobrir como algo funciona que já é complexo o suficiente.

No entanto, trabalhar em um sistema embarcado secundário envolverá o uso de um compilador cruzado que também pode causar problemas. Se você tem um sistema x86 mais antigo disponível, use-o - acostume-se a configurar o sistema a partir do zero, pois você o iniciará mais cedo ou mais tarde e o exercício de fazer isso não é uma coisa ruim, como o desenvolvimento real do kernel envolverá o desenvolvimento em sistemas menos estáveis (cera ligada / cera desligada ...).

Na ausência de qualquer sistema secundário para invadir, dual boot seu sistema principal e use o segundo sistema para trabalhar - mas certifique-se de fazer backup de tudo, apenas no caso.

Ah, e um pensamento final - não use o Ubuntu, o fedora ou qualquer distribuição onde o espaço do usuário possa mudar entre as atualizações - caso contrário, você acabará depurando problemas com fantasmas. Use Debian, centos ou outro espaço de usuário estável, pelo menos até que você consiga detectar instintivamente tais problemas.