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

Powered by blists - more mailing lists