linux-ext4 - New archtecture support in xfstests-bld

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Sun, 22 Oct 2023 22:34:17 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     "Ritesh Harjani (IBM)" <ritesh.list@...il.com>
Cc:     linux-ext4@...r.kernel.org, Ojaswin Mujoo <ojaswin@...ux.ibm.com>,
        ebiggers@...gle.com, fstests@...r.kernel.org
Subject: New archtecture support in xfstests-bld

Hey Ritesh,

I just pulled some changes from Eric Biggers into xfstests-bld which
has a start on adding riscv64 support to kvm-xfstests.  So far, he's
updated libaio to a newer upstream version (newer is relative; the
"new" version was last updated six years ago :-) for better RiscV
support, and he's added RiscV support to set_canonicalized_arch().

I'd recommend that you start with the latest upstream version of
xfstests-bld, and then add support for powerpcle64 by adding support
to find_kernel_to_use() in run=fstests/util/parse_opt_funcs, and
set_cross_compile() and get_kernel_file_info() in
run-fstests/util-arch, since those changes in the 2/2 patch series[1]
were clearly correct.  (And Eric, you should take a look at those
changes[1] for RiscV support.)

[1] https://lore.kernel.org/all/eb1f8f0fb0ff9a6358129a2a45bd0c88421ac669.1696965271.git.ritesh.list@gmail.com/

I'd also encourage you to add support for the new architectures in
selftests/appliance, since that will exercise building a kernel for
the foreign architecture using cross-compilation, and then using
qemu-system-$ARCH from kvm-xfstests.

(Yes, kvm-xfstests is starting to get very much misnamed; but kvm is
easier to type, and autocompletes much more nicely than qemu-<tab>.
The string "kvm" also is sprinkled all over the xfstests-bld scripts,
and I'm not convinced it's worth changing.  That being said, I've
added a qemu-xfstests script which gets installed into the user's bin
directory; we'll see if that is something people feel strongly about
using the new name.)

Finally, since have two separate efforts to add support for new
architectures to xfstests-bld, might I prevail on you to keep some
notes about what's needed to bootstrap a new architecture?  That might
be helpful for some future developer.

Many thanks!

					- Ted