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.
If for your cases, this winds up taking 3 days to run instead of the
minutes mine needs, so be it, that's a small workflow adjustment thing.
You might not get the same dopamine feedback loop of seeing your changes
in action and deployed to users _now_, but maybe delaying the
gratification a bit will be good anyway.
Jason
