[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