From: Petr Vorel <pvorel@suse.cz>
To: Rob Landley <rob@landley.net>
Cc: Cyril Hrubis <chrubis@suse.cz>,
Geert Uytterhoeven <geert@linux-m68k.org>,
ltp@lists.linux.it, Li Wang <liwang@redhat.com>,
Andrea Cervesato <andrea.cervesato@suse.com>,
Greg Ungerer <gerg@linux-m68k.org>,
Jonathan Corbet <corbet@lwn.net>,
Randy Dunlap <rdunlap@infradead.org>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Christophe Lyon <christophe.lyon@linaro.org>,
linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
Linux-sh list <linux-sh@vger.kernel.org>,
automated-testing@lists.yoctoproject.org,
buildroot@buildroot.org, Niklas Cassel <niklas.cassel@wdc.com>
Subject: Re: 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
WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: Rob Landley <rob@landley.net>
Cc: Cyril Hrubis <chrubis@suse.cz>,
Geert Uytterhoeven <geert@linux-m68k.org>,
ltp@lists.linux.it, Li Wang <liwang@redhat.com>,
Andrea Cervesato <andrea.cervesato@suse.com>,
Greg Ungerer <gerg@linux-m68k.org>,
Jonathan Corbet <corbet@lwn.net>,
Randy Dunlap <rdunlap@infradead.org>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Christophe Lyon <christophe.lyon@linaro.org>,
linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
Linux-sh list <linux-sh@vger.kernel.org>,
automated-testing@lists.yoctoproject.org,
buildroot@buildroot.org, Niklas Cassel <niklas.cassel@wdc.com>
Subject: Re: 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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
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
WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: Rob Landley <rob@landley.net>
Cc: Cyril Hrubis <chrubis@suse.cz>,
Geert Uytterhoeven <geert@linux-m68k.org>,
ltp@lists.linux.it, Li Wang <liwang@redhat.com>,
Andrea Cervesato <andrea.cervesato@suse.com>,
Greg Ungerer <gerg@linux-m68k.org>,
Jonathan Corbet <corbet@lwn.net>,
Randy Dunlap <rdunlap@infradead.org>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Christophe Lyon <christophe.lyon@linaro.org>,
linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
Linux-sh list <linux-sh@vger.kernel.org>,
automated-testing@lists.yoctoproject.org,
buildroot@buildroot.org, Niklas Cassel <niklas.cassel@wdc.com>
Subject: Re: 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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-01-10 22:33 UTC|newest]
Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-03 1:52 [PATCH 00/36] Remove UCLINUX from LTP Petr Vorel
2024-01-03 1:52 ` [LTP] " Petr Vorel
2024-01-03 7:58 ` Cyril Hrubis
2024-01-03 7:58 ` [LTP] " Cyril Hrubis
2024-01-03 8:04 ` Cyril Hrubis
2024-01-03 8:04 ` Cyril Hrubis
2024-01-03 8:39 ` Petr Vorel
2024-01-03 8:39 ` Petr Vorel
2024-01-03 9:46 ` Geert Uytterhoeven
2024-01-03 9:46 ` Geert Uytterhoeven
2024-01-03 9:46 ` [LTP] " Geert Uytterhoeven
2024-01-03 9:46 ` Geert Uytterhoeven
2024-01-03 11:49 ` Petr Vorel
2024-01-03 11:49 ` Petr Vorel
2024-01-03 11:49 ` [LTP] " Petr Vorel
2024-01-03 11:49 ` Petr Vorel
2024-01-03 11:54 ` Geert Uytterhoeven
2024-01-03 11:54 ` Geert Uytterhoeven
2024-01-03 11:54 ` [LTP] " Geert Uytterhoeven
2024-01-03 11:54 ` Geert Uytterhoeven
2024-01-03 12:09 ` Cyril Hrubis
2024-01-03 12:09 ` Cyril Hrubis
2024-01-03 12:09 ` [LTP] " Cyril Hrubis
2024-01-03 12:09 ` Cyril Hrubis
2024-01-03 12:40 ` Petr Vorel
2024-01-03 12:40 ` Petr Vorel
2024-01-03 12:40 ` [LTP] " Petr Vorel
2024-01-03 12:40 ` Petr Vorel
2024-01-05 3:52 ` Rob Landley
2024-01-05 3:52 ` Rob Landley
2024-01-05 3:52 ` [LTP] " Rob Landley
2024-01-05 3:52 ` Rob Landley
2024-01-05 13:11 ` [Buildroot] Call for nommu LTP maintainer [was: Re: [PATCH 00/36] Remove UCLINUX from LTP] Petr Vorel
2024-01-05 13:11 ` Petr Vorel
2024-01-05 13:11 ` [LTP] " Petr Vorel
2024-01-05 13:11 ` Petr Vorel
2024-01-05 13:11 ` Petr Vorel
2024-01-06 3:58 ` [Buildroot] " Rob Landley
2024-01-06 3:58 ` Rob Landley
2024-01-06 3:58 ` [LTP] " Rob Landley
2024-01-06 3:58 ` Rob Landley
2024-01-06 3:58 ` Rob Landley
2024-01-08 9:03 ` [Buildroot] " Petr Vorel
2024-01-08 9:03 ` Petr Vorel
2024-01-08 9:03 ` [LTP] " Petr Vorel
2024-01-08 9:03 ` Petr Vorel
2024-01-08 9:03 ` Petr Vorel
2024-01-08 10:07 ` Cyril Hrubis
2024-01-08 10:07 ` Cyril Hrubis
2024-01-08 10:07 ` [LTP] " Cyril Hrubis
2024-01-08 10:07 ` Cyril Hrubis
2024-01-09 22:37 ` [Automated-testing] " Bird, Tim
2024-01-09 22:37 ` Bird, Tim
2024-01-09 22:37 ` [LTP] " Bird, Tim
2024-01-09 22:37 ` Bird, Tim
2024-01-10 5:01 ` [Buildroot] " Rob Landley
2024-01-10 5:01 ` Rob Landley
2024-01-10 5:01 ` [LTP] " Rob Landley
2024-01-10 5:01 ` Rob Landley
2024-01-10 5:01 ` Rob Landley
2024-01-10 14:14 ` Petr Vorel
2024-01-10 14:14 ` Petr Vorel
2024-01-10 14:14 ` [LTP] " Petr Vorel
2024-01-10 14:14 ` Petr Vorel
2024-01-10 19:23 ` [Buildroot] " Rob Landley
2024-01-10 19:23 ` Rob Landley
2024-01-10 19:23 ` [LTP] " Rob Landley
2024-01-10 19:23 ` Rob Landley
2024-01-10 19:23 ` Rob Landley
2024-01-10 21:17 ` [Buildroot] " Niklas Cassel via buildroot
2024-01-10 21:17 ` Niklas Cassel
2024-01-10 21:17 ` [LTP] " Niklas Cassel via ltp
2024-01-10 21:17 ` Niklas Cassel
2024-01-10 21:17 ` Niklas Cassel
2024-01-11 0:00 ` Greg Ungerer
2024-01-11 0:00 ` Greg Ungerer
2024-01-11 0:00 ` [LTP] " Greg Ungerer
2024-01-11 0:00 ` Greg Ungerer
2024-01-11 9:21 ` [Buildroot] " Niklas Cassel via buildroot
2024-01-11 9:21 ` Niklas Cassel
2024-01-11 9:21 ` [LTP] " Niklas Cassel via ltp
2024-01-11 9:21 ` Niklas Cassel
2024-01-11 9:21 ` Niklas Cassel
2024-01-12 20:18 ` [Buildroot] " Rob Landley
2024-01-12 20:18 ` Rob Landley
2024-01-12 20:18 ` [LTP] " Rob Landley
2024-01-12 20:18 ` Rob Landley
2024-01-12 20:18 ` Rob Landley
2024-01-11 2:25 ` Greg Ungerer
2024-01-11 2:25 ` Greg Ungerer
2024-01-11 2:25 ` [LTP] " Greg Ungerer
2024-01-11 2:25 ` Greg Ungerer
2024-01-12 20:16 ` [Buildroot] " Rob Landley
2024-01-12 20:16 ` Rob Landley
2024-01-12 20:16 ` [LTP] " Rob Landley
2024-01-12 20:16 ` Rob Landley
2024-01-12 20:16 ` Rob Landley
2024-01-14 13:01 ` Greg Ungerer
2024-01-14 13:01 ` Greg Ungerer
2024-01-14 13:01 ` [LTP] " Greg Ungerer
2024-01-14 13:01 ` Greg Ungerer
2024-01-15 13:41 ` [Buildroot] " Waldemar Brodkorb
2024-01-15 13:41 ` Waldemar Brodkorb
2024-01-15 13:41 ` [LTP] " Waldemar Brodkorb
2024-01-15 13:41 ` Waldemar Brodkorb
2024-01-15 13:41 ` Waldemar Brodkorb
2024-01-15 14:22 ` Cyril Hrubis
2024-01-15 14:22 ` Cyril Hrubis
2024-01-15 14:22 ` [LTP] " Cyril Hrubis
2024-01-15 14:22 ` Cyril Hrubis
2024-01-11 13:11 ` Geert Uytterhoeven
2024-01-11 13:11 ` Geert Uytterhoeven
2024-01-11 13:11 ` [LTP] " Geert Uytterhoeven
2024-01-11 13:11 ` Geert Uytterhoeven
2024-01-11 13:19 ` Greg Ungerer
2024-01-11 13:19 ` Greg Ungerer
2024-01-11 13:19 ` [LTP] " Greg Ungerer
2024-01-11 13:19 ` Greg Ungerer
2024-01-09 20:24 ` [Buildroot] " Rob Landley
2024-01-09 20:24 ` Rob Landley
2024-01-09 20:24 ` [LTP] " Rob Landley
2024-01-09 20:24 ` Rob Landley
2024-01-09 20:24 ` Rob Landley
2024-01-09 23:17 ` Greg Ungerer
2024-01-09 23:17 ` Greg Ungerer
2024-01-09 23:17 ` [LTP] " Greg Ungerer
2024-01-09 23:17 ` Greg Ungerer
2024-01-10 5:47 ` [Buildroot] " Rob Landley
2024-01-10 5:47 ` Rob Landley
2024-01-10 5:47 ` [LTP] " Rob Landley
2024-01-10 5:47 ` Rob Landley
2024-01-10 5:47 ` Rob Landley
2024-01-10 14:46 ` Greg Ungerer
2024-01-10 14:46 ` Greg Ungerer
2024-01-10 14:46 ` [LTP] " Greg Ungerer
2024-01-10 14:46 ` Greg Ungerer
2024-01-10 13:33 ` Petr Vorel
2024-01-10 13:33 ` Petr Vorel
2024-01-10 13:33 ` [LTP] " Petr Vorel
2024-01-10 13:33 ` Petr Vorel
2024-01-10 18:23 ` [Buildroot] " Rob Landley
2024-01-10 18:23 ` Rob Landley
2024-01-10 18:23 ` [LTP] " Rob Landley
2024-01-10 18:23 ` Rob Landley
2024-01-10 18:23 ` Rob Landley
2024-01-10 22:33 ` Petr Vorel [this message]
2024-01-10 22:33 ` Petr Vorel
2024-01-10 22:33 ` [LTP] " Petr Vorel
2024-01-10 22:33 ` Petr Vorel
2024-01-08 8:33 ` [PATCH 00/36] Remove UCLINUX from LTP Andrea Cervesato
2024-01-08 8:33 ` Andrea Cervesato
2024-01-08 8:33 ` [LTP] " Andrea Cervesato via ltp
2024-01-08 8:33 ` Andrea Cervesato
2024-01-08 8:34 ` Andrea Cervesato
2024-01-08 8:34 ` Andrea Cervesato
2024-01-08 8:34 ` [LTP] " Andrea Cervesato via ltp
2024-01-08 8:34 ` Andrea Cervesato
2024-01-05 3:50 ` Rob Landley
2024-01-05 3:50 ` Rob Landley
2024-01-05 3:50 ` [LTP] " Rob Landley
2024-01-05 3:50 ` Rob Landley
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=andrea.cervesato@suse.com \
--cc=automated-testing@lists.yoctoproject.org \
--cc=buildroot@buildroot.org \
--cc=christophe.lyon@linaro.org \
--cc=chrubis@suse.cz \
--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=liwang@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.