From: Petr Vorel <pvorel@suse.cz>
To: Rob Landley <rob@landley.net>
Cc: Niklas Cassel <niklas.cassel@wdc.com>,
Jonathan Corbet <corbet@lwn.net>,
Linux-sh list <linux-sh@vger.kernel.org>,
Christophe Lyon <christophe.lyon@linaro.org>,
Randy Dunlap <rdunlap@infradead.org>,
linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
linux-riscv <linux-riscv@lists.infradead.org>,
buildroot@buildroot.org, Greg Ungerer <gerg@linux-m68k.org>,
ltp@lists.linux.it, automated-testing@lists.yoctoproject.org
Subject: Re: [LTP] Call for nommu LTP maintainer [was: Re: [PATCH 00/36] Remove UCLINUX from LTP]
Date: Wed, 10 Jan 2024 23:33:32 +0100 [thread overview]
Message-ID: <20240110223332.GA1797182@pevik> (raw)
In-Reply-To: <c065bbb0-e5cb-04ae-cedc-258264162405@landley.net>
> On 1/10/24 07:33, Petr Vorel wrote:
> >> I'm a bit weird in that I try to get CURRENT stuff to work on nommu, and a lot
> >> of people have been happy to consume my work, but getting any of them to post
> >> directly to linux-kernel is like pulling teeth.
> > Interesting, thanks for sharing this. BTW I'm not saying anybody is using nommu,
> > but I wonder if anybody really test it with LTP. And if yes, I wonder why we
> > don't have reports about tests broken in new API.
> I don't expect a lot of nommu users are aware you ever _could_ run LTP on nommu.
> But I'd like to get nommu more regularly supported. You _should_ be able to
> build a musl-linux userspace with busybox or toybox and be able to build a
> recognizable system (even an alpine-alike) which could then get the basic
> plumbing regression tested on qemu even without access to nommu hardware.
> >> > 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).
> >> What does the API migration do? Is there a page on it ala OABI vs EABI in arm or
> >> something?
> > New C API is documented at our wiki: the API for using in the tests [1]
> > and the library itself [2]. (We also have shell API, but we can ignore it for
> > nommu.)
> I'm writing a bash-compatible shell, which (thanks to Elliott forwarding
> questions) has involved surprisingly long threads with the bash maintainer about
> weird corner cases neither the man page nor my testing made clear:
> http://lists.landley.net/pipermail/toybox-landley.net/2023-July/029631.html
> (Alas I try NOT to involve him because when I bring stuff up he keeps FIXING
> BASH which from my point of view just makes it a moving target...)
> Anyway, running the shell API on nommu doesn't seem out of the question, but
> probably not any time soon. (The fact the shell isn't finished yet is one of the
> big REASONS I haven't got enough time to take on LTP. That and I haven't started
> writing "awk" and "make" yet". And I need to cycle back to
> https://landley.net/notes-2023.html#12-10-2023 . And after that debian, ala
> https://peertube.debian.social/w/chzkKrMvEczG7qQyjbMKPr and
> https://peertube.debian.social/w/45XroN9CnbYLNLKQH3GD9F . And follow up on
> https://lists.gnu.org/archive/html/coreutils/2023-08/msg00009.html . And...)
> > All files in lib/ directory which include tst_test.h are part of new C API. Main
> > file is lib/tst_test.c.
> safe_fork(), safe_clone(), fork_testrun()...
> > LTP tests, which has been rewritten to new API include
> > tst_test.h, they are in testcases/ directory. Library has it's own tests (for
> > testing regression in in lib/newlib_tests/*.c.
> Library meaning... libc? Or does LTP have a library?
Yes, LTP has a library (lib/libltp.a). That's what I meant here and in all my
text. So far I did not mention anything libc specific.
> > The reason why Cyril wrote in 2016 new C API was that the old API was buggy
> > (tests randomly fails). Tests which are still using the old API (there is
> > ongoing rewrite) include test.h. The old API is not much documented.
> > Feel free to ask any more question.
> My standard questions are "what does success look like" and "how do I reproduce
> the problem".
> For the first: if there previously was nommu support in LTP, what's the last
> version that's known to work? Is there an existing build/test setup that can be
> reproduced?
I have no idea whether it worked. Best would be to ask Mike Frysinger (the
author of m4/ltp-nommu-linux.m4). The code was added 14 years ago, even before
all of the current maintainers were involved.
> For the second... If I try to run LTP on sh2eb (my current nommu test board)
> with the current LTP... do I get a build break? Additional test failures at
> runtime? You talk about "removing nommu support", but... what's the current
> status? (A subset of tests still use the old api...?)
Yes, subset of the tests which use the old API (git grep UCLINUX).
> Yes I need to read https://github.com/linux-test-project/ltp/wiki/C-Test-API but
> I also need to know how to build LTP from source. I'm looking at the README's
> list of "autoconf, automake, m4, pkgconf / pkg-config" and wincing
> significantly. (What does gnu/autoconf DO here? Disable tests? I never
> understand why anybody uses that giant hairball of complexity. Half of cross
> compiling is figuring out how to lie to autoconf, and my normal workaround for
> that is to bootstrap a target system and build natively, but while I've gotten
> gcc to run natively on nommu systems, I never _tried_ gnu/autoconf.
> Bootstrapping some subset of LFS on a nommu system so it has the dependencies
> LFS needs to natively build seems like the long way 'round...
Well, one day we might migrate to use something else (meson?), but until then
autoconf + m4 + pkgconf is used (instead of automake there is LTP custom
system). This was written in 2009 and nobody plans to change it (well, Andrea
played with meson [1] [2]). But we got far away from the original topic :).
Kind regards,
Petr
[1] https://github.com/acerv/ltp-core
[2] https://github.com/acerv/ltp-testcases
> (I am not the right guy for "make it work the easy way". I am the guy who will
> step on every land mine between here and there. I code by debugging an empty
> screen. If I don't start from "known working" setup... it would take a while.)
> Rob
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2024-01-10 22:33 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-03 1:52 [LTP] [PATCH 00/36] Remove UCLINUX from LTP Petr Vorel
2024-01-03 7:58 ` Cyril Hrubis
2024-01-03 8:04 ` Cyril Hrubis
2024-01-03 8:39 ` Petr Vorel
2024-01-03 9:46 ` Geert Uytterhoeven
2024-01-03 11:49 ` Petr Vorel
2024-01-03 11:54 ` Geert Uytterhoeven
2024-01-03 12:09 ` Cyril Hrubis
2024-01-03 12:40 ` Petr Vorel
2024-01-05 3:52 ` Rob Landley
2024-01-05 13:11 ` [LTP] Call for nommu LTP maintainer [was: Re: [PATCH 00/36] Remove UCLINUX from LTP] Petr Vorel
2024-01-06 3:58 ` Rob Landley
2024-01-08 9:03 ` Petr Vorel
2024-01-08 10:07 ` Cyril Hrubis
2024-01-09 22:37 ` [LTP] [Automated-testing] " Bird, Tim
2024-01-10 5:01 ` Rob Landley
2024-01-10 14:14 ` Petr Vorel
2024-01-10 19:23 ` Rob Landley
2024-01-10 21:17 ` Niklas Cassel via ltp
2024-01-11 0:00 ` Greg Ungerer
2024-01-11 9:21 ` Niklas Cassel via ltp
2024-01-12 20:18 ` Rob Landley
2024-01-11 2:25 ` Greg Ungerer
2024-01-12 20:16 ` Rob Landley
2024-01-14 13:01 ` Greg Ungerer
2024-01-15 13:41 ` [LTP] [Buildroot] " Waldemar Brodkorb
2024-01-15 14:22 ` Cyril Hrubis
2024-01-11 13:11 ` [LTP] " Geert Uytterhoeven
2024-01-11 13:19 ` Greg Ungerer
2024-01-09 20:24 ` [LTP] " Rob Landley
2024-01-09 23:17 ` Greg Ungerer
2024-01-10 5:47 ` Rob Landley
2024-01-10 14:46 ` Greg Ungerer
2024-01-10 13:33 ` Petr Vorel
2024-01-10 18:23 ` Rob Landley
2024-01-10 22:33 ` Petr Vorel [this message]
2024-01-08 8:33 ` [LTP] [PATCH 00/36] Remove UCLINUX from LTP Andrea Cervesato via ltp
2024-01-08 8:34 ` Andrea Cervesato via ltp
2024-01-05 3:50 ` Rob Landley
2024-01-31 0:05 [LTP] Call for nommu LTP maintainer [was: Re: [PATCH 00/36] Remove UCLINUX from LTP] Giovanni Lostumbo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240110223332.GA1797182@pevik \
--to=pvorel@suse.cz \
--cc=automated-testing@lists.yoctoproject.org \
--cc=buildroot@buildroot.org \
--cc=christophe.lyon@linaro.org \
--cc=corbet@lwn.net \
--cc=geert@linux-m68k.org \
--cc=gerg@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-sh@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=niklas.cassel@wdc.com \
--cc=rdunlap@infradead.org \
--cc=rob@landley.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).