* Re: How to quick test/debug in linux kernel?
2024-08-16 11:05 How to quick test/debug in linux kernel? jwbda
@ 2024-08-19 3:50 ` Theodore Ts'o
0 siblings, 0 replies; 2+ messages in thread
From: Theodore Ts'o @ 2024-08-19 3:50 UTC (permalink / raw)
To: jwbda; +Cc: linux-kernel@vger.kernel.org
On Fri, Aug 16, 2024 at 11:05:31AM +0000, jwbda wrote:
>
> Hi guys, would you mind help me with this:
> How to quick test/debug in linux kernel?
>
> Here is my method:
> Make some changes to the source code, add this line of code `printk(KERN_INFO ">>> run in kernel!\n");`
>
> Then compile and run
>
> ```sh
> make -j12
> sudo qemu-system-x86_64 -hda ./mybuild/mylinux.img -m 4096 --enable-kvm -kernel ./linux/arch/x86_64/boot/bzImage -append "root=/dev/sda rw console=ttyS0" -nographic
> ```
> Then check the results in the console. But I think this method is still a bit cumbersome. May I ask how do you quickly test/debug in linux kernel?
Since I'm file system developer, I have my own test appliance which is
optimized for running test kernels via KVM and on GCE. For more
information, see:
https://thunk.org/gce-xfstests
https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md
https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-xfstests.md
The quick version: after installing xfstest-bld, I just run these commands:
# This will install kernel config that is suitable for use with
# kvm-xfstests or gce-xfstests
install-kconfig
# This is a convenience script that will build the kernel, with
# some options if you are using a separate build directores, which
# is handy if you are building for multiple CPU architectures, i.e.,
#x86_64, i386, and/or arm64
kbuild
# This will launch a VM using qemu/kvm using the just-built kernel.
kvm-xfstest shell
(Note: "kvm-xfstests shell" is morally equivalent to your
qemu-system-x86_64 command. For example, if you run "kvm-fstests
shell --noaction" you'll see that it runs a *very* long command that
begins "ionice -n 5 qemu-system-x86_64 -boot order=c -net none ...")
If you are testing a file system change, you can kick off a file
system smoke test via:
kvm-xfstests smoke
And if you have gce-xfstests set up, I will run multiple VM's for
different file sytem configurations using a command such as:
gce-xfstest ltm -c ext4/all -g auto
The above command will create 12 Cloud VM's using Google Compute
Engine, run them in parallel, and then coalesce the result into a
single test report, and e-mail it to me. It takes a little over two
hours of wall clock time, but it runs about 24 hours worth of tests.
So while I *could* run:
kvm-xfstests -c ext4/all -g auto
... I'm too impatient, and using Google Cloud costs about two
dollars (USD), and saves me more than 10x the test time.
The whole system system is set up for development velocity; in
general, you only need to run install-kconfig once, unless you are
moving to a new kernel version, or you want to use different build
options ---- such as "install-kconfig --lockdep", or "install-kconfig
--kasan", etc. And as I mentioned you can build for different
architectures if you have cross-build compilers installed, via
commands such as "install-kconfig --arch arm66" and "install-kconfig
--arch arm64". Both kvm-xfstests and gce-xfstests support using
alternate architectures; using kvm-xfstest it will use qemu to run
with CPU emulation, and with gce-xfstests, Google Cloud supports arm64
VM's, so you can build an arm64 binary, and then gce-xfstests will
launch an arm VM and boot the kernel in that VM.
In general, my development workflow is:
1) Hack the kernel, or apply patches sent by ext4 developers for review
2) Run kbuild
3) Run "kvm-xfstests shell" or "kvm-xfstests smoke"
And after applying a number of patches, I'll kick off a full
regression test build via "gce-xfstests ltm -c ext4/all -g auto" and
then come back after lunch or dinner and check for any new test
failures.
Cheers,
- Ted
^ permalink raw reply [flat|nested] 2+ messages in thread