Date: Mon, 8 Jan 2024 10:03:38 +0100
From: Petr Vorel <pvorel@...e.cz>
To: Rob Landley <rob@...dley.net>
Cc: Cyril Hrubis <chrubis@...e.cz>,
	Geert Uytterhoeven <geert@...ux-m68k.org>, ltp@...ts.linux.it,
	Li Wang <liwang@...hat.com>,
	Andrea Cervesato <andrea.cervesato@...e.com>,
	Greg Ungerer <gerg@...ux-m68k.org>,
	Jonathan Corbet <corbet@....net>,
	Randy Dunlap <rdunlap@...radead.org>,
	John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
	Christophe Lyon <christophe.lyon@...aro.org>,
	linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org,
	Linux ARM <linux-arm-kernel@...ts.infradead.org>,
	linux-riscv <linux-riscv@...ts.infradead.org>,
	Linux-sh list <linux-sh@...r.kernel.org>,
	automated-testing@...ts.yoctoproject.org, buildroot@...ldroot.org,
	Niklas Cassel <niklas.cassel@....com>
Subject: Re: Call for nommu LTP maintainer [was: Re: [PATCH 00/36] Remove
 UCLINUX from LTP]

Hi Rob, all,

[ Added Niklas Cassel, who is maintainer of qemu_riscv64_nommu_virt_defconfig in
buildroot ]

> On 1/5/24 07:11, Petr Vorel wrote:
> >> Nobody is maintaining "uclinux" because that was a distro, but you can build
> >> nommu support in buildroot and such, and people do.

> > Right, there are nommu users. Will anybody join LTP development to maintain
> > nommu support in LTP? The needed work is to add this support to LTP new C API
> > [1] and use it in the relevant test. There is some implementation in the old
> > API, I have no idea how well it worked.

> > If nobody stands for maintaing nommu, we will have to delete it. There is nobody
> > from the current maintainers who is using LTP on nommu HW (that is the reason why
> > nommu support have not been implemented in the new API).

> I'm interested, but overwhelmed. Not sure I've got the spoons to come up to
> speed on a new project and give it regular attention just now.

> I see you cc'd buildroot (although the message might not go through if you
> aren't subscribed, dunno how clogged their moderation queue is these days, and
> the cc: list is long enough it might twig anyway). They had a nommu fix go in
> earlier this week (commit 98684ba7885b).

> That said, qemu supports several nommu platforms and buildroot has defconfigs to
> build systems for them:

> $ git clone git://buildroot.org/buildroot
> $ make help
> $ make list-defconfigs | grep qemu
> $ make qemu_ppc_bamboo_defconfig
> $ make
>   (time passes...)
> >>> host-gettext-tiny 0.3.2 Extracting
> gzip -d -c
> /home/landley/buildroot/buildroot/dl/gettext-tiny/gettext-tiny-0.3.2.tar.gz |
> tar --strip-components=1 -C
> /home/landley/buildroot/buildroot/output/build/host-gettext-tiny-0.3.2   -xf -
> mkdir -p
> /home/landley/buildroot/buildroot/output/build/host-gettext-tiny-0.3.2/gettext-gnu
> xzcat /home/landley/buildroot/buildroot/dl/gettext-tiny/gettext-0.22.4.tar.xz |
> tar --strip-components=1 -C
> /home/landley/buildroot/buildroot/output/build/host-gettext-tiny-0.3.2/gettext-gnu
>  -xf -
> xzcat: /home/landley/buildroot/buildroot/dl/gettext-tiny/gettext-0.22.4.tar.xz:
> No such file or directory
> tar: This does not look like a tar archive
> tar: Exiting with failure status due to previous errors
> make: *** [package/pkg-generic.mk:209:
> /home/landley/buildroot/buildroot/output/build/host-gettext-tiny-0.3.2/.stamp_extracted]
> Error 2


> Sigh, never build git pull du jour of anything, buildroot's having glitch du
> jour. But the point is:

> $ grep -rl bamboo board/
> board/qemu/ppc-bamboo/readme.txt
> $ cat board/qemu/ppc-bamboo/readme.txt
> Run the emulation with:

> qemu-system-ppc -nographic -M bamboo -kernel output/images/vmlinux -net
> nic,model=virtio-net-pci -net user # qemu_ppc_bamboo_defconfig

> The login prompt will appear in the terminal that started Qemu
> -------------------

> In THEORY, once it builds an image (presumably using a tagged release version
> rather than expecting "continuous integration" to ever mean anything) you should
> be able to launch it with qemu. Assuming the instructions aren't also
> bit-rotted. (Or using one of the other nommu boards, I haven't gone through the
> whole list to see what they've got. I used to use a nommu arm board, but the
> linux kernel broke it when converting everything to device tree and not
> regression testing it.)

> Buildroot also apparently has an LTP package selectable in menuconfig:

> https://github.com/buildroot/buildroot/tree/master/package/ltp-testsuite

> But I haven't tried it...

I'm the maintainer of the LTP package in buildroot in my private time.
BTW I spent quite a lot of time fixing LTP (and some other system packages,
e.g. nfs-utils) compilation on some old legacy architectures reported via
http://autobuild.buildroot.net/ I've never used in the reality.
But I certainly don't have time to drive nommu support in my private time.
I don't even have an interest, I don't use any nommu device.

And I would not justify to work on nommu in my working paid by SUSE, because
that's not a platform SUSE uses. Lack of resources means that there is a vast
majority of new kernel functionality not being tested. Also with very small
resources it's hard to even fix existing tests broken by changed functionality
in each mainline kernel release.

Therefore nobody who is not involved in nommu will not find a time to support it
in LTP (support does not mean just to add the functionality to the new C API,
but run tests on nommu and fix failing bugs). I suppose nobody is paid to work
on nommu platforms, it would have to be a hobby project, right?

But as I said, if anybody from nommu decides to maintain it in LTP, I'll try to
support him in my free time (review patches, give advices). And if nobody
stands, this patchset which removes the support in the old API will be merged
after next LTP release (in the end of January).

Kind regards,
Petr

> Rob

> P.S. I automate qemu testing all the time over in toybox, see testroot.sh under
> https://github.com/landley/toybox/tree/master/mkroot for an example.

Powered by blists - more mailing lists