On Mon, Oct 07, 2024 at 05:01:55PM GMT, Jason A. Donenfeld wrote: > On Sun, Oct 06, 2024 at 03:29:51PM -0400, Kent Overstreet wrote: > > But - a big gap right now is endian /portability/, and that one is a > > pain to cover with automated tests because you either need access to > > both big and little endian hardware (at a minumm for creating test > > images), or you need to run qemu in full-emulation mode, which is pretty > > unbearably slow. > > It's really not that bad, at least for my use cases: > > https://www.wireguard.com/build-status/ > > This thing sends pings to my cellphone too. You can poke around in > tools/testing/selftests/wireguard/qemu/ if you're curious. It's kinda > gnarly but has proven very very flexible to hack up for whatever > additional testing I need. For example, I've been using it for some of > my recent non-wireguard work here: https://git.zx2c4.com/linux-rng/commit/?h=jd/vdso-test-harness > > Taking this straight-up probably won't fit for your filesystem work, but > maybe it can act as a bit of motivation that automated qemu'ing can > generally work. It has definitely caught a lot of silly bugs during > development time. I have all the qemu automation: https://evilpiepirate.org/git/ktest.git/ That's what I use for normal interactive development, i.e. I run something like build-test-kernel -I ~/ktest/tests/fs/bcachefs/replication.ktest rereplicate which builds a kernel, launches a VM and starts running a test; test output on stdout, I can ssh in, ctrl-c kills it like any other test. And those same tests are run automatically by my CI, which watches various git branches and produces results here: https://evilpiepirate.org/~testdashboard/ci?user=kmo&branch=bcachefs-testing (Why yes, thas is a lot of failing tests still.) I'm giving out accounts on this to anyone in the community doing kernel development, we've got fstests wrappers for every local filesystem, plus nfs, plus assorted other tests. Can always use more hardware if anyone wants to provide more machines.
