Linuxデバイスドライバテスト環境の構築

Linuxデバイスドライバテスト環境の構築

作業中にテスト環境を設定する最良の方法は何ですかLinuxデバイスドライバ

x86_64_defconfigを使用して、最新のLinuxソースからx86用のbzImageをコンパイルしました。

私はフォローしましたGentooカスタムinitramfsチュートリアルこれにより、Busyboxベースの隔離されたファイルシステムから起動できます。私はそれらが使用するのと同じ初期化ファイルを使用します。私がすることと彼らがすることの唯一の違いは、私がUbuntuで実行し、Emergeを使用する代わりに、最新のBusybox x86_64バイナリをダウンロードすることです。

私はUbuntu 16.04システムで動作しています。

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

これはcustom-initramfs.cpio.gzGentooチュートリアルで私が作成して圧縮したinitramfsを表します。

これらすべてを実行しましたが、以下のようにカーネルエラーが発生しました。

[    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)

ただし、QEMUを使用せずにローカルで起動する場合は、initramfsで起動できます。このgrubメニューオプションは機能します

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

ここで、bzImageとinitramfsは、同じデフォルトのx86_64構成カーネルイメージと以前に構築されたカスタムinitramfsを参照します。

問題は、QEMUが/devローカルシステムと同じデバイスアクセス権を持っていないために発生するようです。

QEMU環境で動作するには何を変更する必要がありますか?私の目標は、カーネルの起動を完了し、一種の最小限のファイルシステムに入ることです。

私は仕事で最初のデバイスドライバパッチを作成しました。本当に興味深く、もっと学びたいです。どんな助けでも大変感謝します!

答え1

ここに独学的なカーネルハッカーがあります(まだまだそのうちの小さな部分を保持しています)。

おそらく明確な答えはあまりないかもしれませんが、まずRaspberry Piなどの小さな組み込みボードを使用することをお勧めします。近い将来、カーネルの開発中に物理ハードウェアを使用する必要があるからです。ソフトウェアシミュレーションと仮想マシンは使用しません。物理ハードウェアプログラムやコードと同じドライバを使用する場合、またはすでに十分に複雑なものがどのように機能するかを調べようとするときは、複雑さの追加の層を追加します。

ただし、セカンダリ組み込みシステムで作業するにはクロスコンパイラを使用する必要があるため、問題が発生する可能性があります。古いx86システムがある場合はそれを使用してください。遅かれ早かれ気になるので、システムを最初から設定することに慣れてください。実際のカーネル開発には作業が伴うので、悪いことではありません。安定性の低いシステムで開発されています(ワックス/ワックス...)。

ハッキングするセカンダリシステムがない場合は、メインシステムをデュアルブートし、セカンダリシステムを業務用に使用してください。しかし、万が一の場合に備えてすべてをバックアップしておいてください。

ああ、そして最後に考えてみると、Ubuntu、Fedora、またはアップデートの間にユーザースペースが変更される可能性があるディストリビューションを使用しないでください。それ以外の場合は、ゴーストの問題をデバッグします。少なくともそのような問題が本能的に発見されるまで、Debian、centos、または他の信頼できるユーザースペースを使用してください。

関連情報