Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
Date:   Sun, 22 Oct 2023 22:34:17 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
Cc:     linux-ext4@vger.kernel.org, Ojaswin Mujoo <ojaswin@linux.ibm.com>,
        ebiggers@google.com, fstests@vger.kernel.org
Subject: New archtecture support in xfstests-bld
Message-ID: <20231023023417.GA1778210@mit.edu>
References: <060d9fef332979fd5d53b1c28c13b2043a16ab25.1696965271.git.ritesh.list@gmail.com>
 <20231012172835.GD255452@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231012172835.GD255452@mit.edu>
Precedence: bulk

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