On Mon, Oct 07, 2024 at 03:59:17PM -0400, Kent Overstreet wrote: > 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/ Neat. I suppose you can try to hook up all the other archs to run in TCG there, and then you'll be able to test big endian and whatever other weird issues crop up.
