Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [hwloc-devel] hwloc testing review
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2012-11-06 16:02:52

Le 06/11/2012 21:48, John Brier a écrit :
> Hi folks. I've been using Linux since 2000 and supporting it with Red
> Hat since 2007 and now I'm a Red Hat Quality Assurance Engineer.
> At Red Hat we use the 'make check' build target to test hwloc. I did a
> review of what that target tests and what it doesn't and this is what I
> found.
> Did I miss anything?
> Are there are additional things that should be tested?
> For the binaries it would be useful for Red Hat (and maybe others) if we
> could use the existing 'make check' build target to test *system
> installed* binaries (aka the ones from our RPM) and not the source
> distributed built ones. Does that seem like a feature that would be
> useful for others and is it possible to add that support to the
> associated autotools files?
> note the comments about untested binaries below

Hello John,

Your list is basically OK.
Some comments below.

> [ ] hwloc-bind
> - not tested. This seems important enough to test.

Basic testing is easy, but it becomes annoying when you want to test
things that may not be supported by the OS. Testing CPU binding on Linux
should be easy. Memory binding too if you check whether the machine is
NUMA first.

> [ ] hwloc-ps
> - isn't tested and that seems like it would be easy to test. I would
> be willing to take a stab at adding that support if that is
> acceptable.

This one also has some Linux specific behavior. I'd be interested to see
if you can get something to work.

> [x] lstopo
> - tested by utils/
> [x] lstopo-no-graphics
> - tested by utils/

These are actually very basically tested. We store most lstopo output to
a file but we don't check its content at all. Obviously, the output
depends on the machine, so in-depth testing isn't easy. But right now,
we somehow just check sure they don't crash.

> = tests/linux/ =
> "This directory contains tarballs of Linux sysfs hierarchies collected on

sysfs + some files from /proc and /proc/device-tree when it matters.

> various systems. Each tarball `xyz.tar.bz2' comes with the corresponding
> `xyz.output', which gives the expected output of "lstopo -v -" for that
> system.

There are also several cases where we add some options to lstopo to
change its behavior, output to XML, ...

> = doc/hwloc-hello =
> - hwloc-hello is the binary of hwloc-hello.c
> - hwloc-hello-cpp is the binary of the hwloc-hello-cpp.cpp source
> program
> - hwloc-hello.c and hwloc-hello-cpp.cpp contain the same C source
> code and are a demonstration of the hwloc C API which is described
> in the docs
> - for testing, the code is compiled and executed

The CPP is only here to make sure that the hwloc C API is C++-acceptable.

> = tests/Makefile check_PROGRAMS =
> - the following C programs test various functions of the C API

All these files are supposed to have header comments saying what they
test, but I wouldn't be surprised if some of those are
outdated/incomplete. At least, they shouldn't test less than what is said.

> hwloc_bind.c
> check the binding functions

And compare with what the "support" bitmap says about what hwloc
supports on this platform.

> xmlbuffer.c
> test hwloc_topology_export_xmlbuffer() and ??

And set_xmlbuffer() for reimporting what we exported.