ltp.lists.linux.it archive mirror
 help / color / mirror / Atom feed
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

  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).