This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Chroot testsuite


On Fri, Jan 10, 2014 at 7:32 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Fri, 10 Jan 2014, Ryan Arnold wrote:
>
>> Creating the chroot is out-of-scope for glibc since the methodology
>> for doing so will vary based on operating system distribution (for
>> example, Ubuntu might use schroot and debootstrap while for Fedora
>> might use systemd-nspawn and yum --installroot).  A wiki how-to would
>> be helpful in any case.  I imagine an OS distribution could also
>> provide a package which does this for their specific src package
>> manager.
>
>> Is there any coverage that's lost by not performing builddir tests
>> remotely if they're all repurposed as install/host tests?
>

> glibc testing should not assume any particular packages on the host; it
> should work even if what you get from ssh is just a busybox shell (with no
> privileges to run chroot).

So for the general case of builddir tests being turned into
host/install tests (i.e., not integration tests), this means that
glibc would copy the local install_root contents onto the remote
machine where the tests will then be executed there by invoking the
test via the dynamic linker <install_root>/elf/ld[64].so <testcase>?

This method doesn't cover integration tests which presume that the
libraries are installed in the specified prefix... but your
GLIBC_SYSROOT (mentioned later) would help solve this problem.

> It should also not require that any OS
> binaries are available that are compatible with the newly built glibc
> rather than being linked with some other incompatible libc (consider, for
> example, testing an x32 glibc when nothing other than the kernel supports
> x32, or testing an ABI-changed glibc as part of bringing up a port).

Is this scenario always remote because it means we're testing in a VM
or can the kernel now support executing more than one ABI?

In any case, these tests should only be executed if the kernel being
executed on can actually satisfy it's side of the preconditions,
otherwise they should simply not be executed.

> So, except where testing something inherently requires chroot, I don't
> think tests for that thing should be limited to environments where chroot
> is a possibility - although it's useful to be able to run the same test
> both ways.  And where chroot is a possibility, being able to test in a
> chroot directory that is exactly what you get from install_root - no other
> software at all - would be desirable.

For the record, I really dislike trying to create minimal chroots by
hand (which is why I proposed debootstrap or yum --installroot for the
general case).

For remotely run host integration tests glibc can remain ignorant of
the fact that it might be running and executing remote tests in a
container/chroot/VM.  Openssh provides a method to forward specific
users directly into chrooted shells.  But this requires scaffolding
being precisely setup outside of the glibc environment.

The preconditions for getting proper successful results from these
tests would be:

Remote host tests:
  SSH keys
  Chroot image
  Local install_root copied to remote chroot prefix directory (i.e.,
not a remote install_root directory).
  Ssh Daemon configuration for giving specific users a chroot shell.
  A sufficiently correct glibc build such that the chroot will
actually successfully boot.
  local tunnel configuration

Local host tests:
  install_root is set to the prefix directory of the chroot.
  a mechanism in glibc that forwards these tests into the chroot.

I recently watched a talk by the maintainer of systemd-nspawn where he
discussed that systemd-nspawn uses the kernel facilities directly that
chroot and other container systems use to setup a container.  We could
do something similar and either execute that code directly on the
build machine against a local chroot or install and execute it on the
remote host so that glibc didn't need to know about chroot commands
directly.. but that seems like overkill just to emulate a few easy
commands.

This all becomes a non-argument if we have GLIBC_SYSROOT.

>
> I do want to be able to run tests against installed glibc without the
> builddir from the original build (in support of a model of building a
> complete cross toolchain, then testing the final complete toolchain) and
> without needing to chroot, but the way I'm thinking of implementing that
> is using appropriate makefile variables that can be overridden for
> installed testing, so that e.g. tests link with $(ld.so-tests) which could
> be an installed file rather than a build tree file, so the dependencies
> don't force most of the library to be built.  That also requires
> distinguishing those tests that inherently examine properties of the build
> tree rather than just installed files, and should have a separate makefile
> target to run them at build time.  It also requires a mechanism to save
> any non-installed build-tree files that really are needed by tests.  I'm
> not planning on working on this until my changes to generate PASS / FAIL
> results are in.

This is what I referred to earlier as invoking remote tests directly
via the install_root dynamic linker isn't it?  I think this is a good
general solution to the problem.

>
> I would not be adverse to the normal glibc testsuite moving to installing
> files in a staging directory within the build tree using install_root,
> then running tests the same way they would be run with a previously built
> and installed glibc, provided this does not require any extra software or
> privileges for chroot.

I think we've sorted out that this is possible to do this for existing
tests that aren't meant to be integration tests that presume they're
executing in the specified prefix.

>
> I've previously suggested a GLIBC_SYSROOT environment variable for use in
> testing, that would allow more of the effects of chroot to be emulated
> without needing any privileges or extra installed software, but there were
> some concerns about having such a variable.

This would be a way around tests that presume they're executing in the
specified prefix (such as ldconfig).  This would also solve other
problems... such as Linux distributions that want to have experimental
toolchains that don't have to have their binaries executed in chroots.
 This also seems like a significant amount of work.

Secondary library integration tests (like running the ruby testsuite)
will probably still require a chroot setup until a GLIBC_SYSROOT
mechanism is fully deployed.. but this can probably remain
out-of-scope for glibc and those of us who care about it can set up
our own environments and scaffolding for doing so.

Ryan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]