[PATCH] tests: Handle system-wide tunables in rseq tests
Michael Jeanson
mjeanson@efficios.com
Thu Jul 2 20:16:41 GMT 2026
On 2026-07-02 11:48, DJ Delorie wrote:
> Yes, the test-container is a chroot we build at test time that has an
> installed glibc and a few utilities (like sh and cp) and a basic
> filesystem (like /etc). It also has the build and source trees mounted
> inside it. "Running a test in a container" means running it with
> support/test-container.c, which manages setting up the container
> (refreshing the install and pre-installing any test-specific files
> needed for the test), running the test in it, and cleaning up the
> container afterwards.
>
> The primary purpose of this system is to allow us to test things that
> need to be tested "live" without interfering with (or being affected by)
> the host OS.
>
> See https://developers.redhat.com/blog/2018/11/16/microcontainers-for-unit-testing
> for some introduction.
I had a quick look and I'm not quite sure how to combine the
'tests-internal' and 'tests-container' targets to allow running
tst-rseq/tst-rseq-disable.
I don't know if the added complexity of the container is really required
given the low probability of the testsuite being run with a system-wide
policy on 'glibc.pthread.rseq'. Reporting the error to the user might be
enough.
Thoughts?
Michael
More information about the Libc-alpha
mailing list