freebsd-nq

History

Stefan Eßer 5e04571cf3 sys/bitset.h: reduce visibility of BIT_* macros Add two underscore characters "__" to names of BIT_* and BITSET_* macros to move them to the implementation name space and to prevent a name space pollution due to BIT_* macros in 3rd party programs with conflicting parameter signatures. These prefixed macro names are used in kernel header files to define macros in e.g. sched.h, sys/cpuset.h and sys/domainset.h. If C programs are built with either -D_KERNEL (automatically passed when building a kernel or kernel modules) or -D_WANT_FREENBSD_BITSET (or this macros is defined in the source code before including the bitset macros), then all macros are made visible with their previous names, too. E.g., both __BIT_SET() and BIT_SET() are visible with either of _KERNEL or _WANT_FREEBSD_BITSET defined. The main reason for this change is that some 3rd party sources including sched.h have been found to contain conflicting BIT_* macros. As a work-around, parts of shed.h have been made conditional and depend on _WITH_CPU_SET_T being set when sched.h is included. Ports that expect the full functionality provided by sched.h need to be built with -D_WITH_CPU_SET_T. But this leads to conflicts if BIT_* macros are defined in that program, too. This patch set makes all of sched.h visible again without this parameter being passed and without any name space pollution due to BIT_* macros becoming visible when sched.h is included. This patch set will be backported to the STABLE branches, but ports will need to use -D_WITH_CPU_SET_T as long as there are supported releases that do not contain these patches. Reviewed by: kib, markj MFC after: 1 month Relnotes: yes Differential Revision: https://reviews.freebsd.org/D33235		2021-12-05 23:00:25 +01:00
..
etc
freebsd_test_suite
sys	sys/bitset.h: reduce visibility of BIT_* macros	2021-12-05 23:00:25 +01:00
Kyuafile
Makefile
Makefile.depend
Makefile.inc0
README

README

src/tests: The FreeBSD test suite
=================================

Usage of the FreeBSD test suite:
(1)  Run the tests:
       kyua test -k /usr/tests/Kyuafile
(2)  See the test results:
       kyua report

For further information on using the test suite, read tests(7):
       man tests

Description of FreeBSD test suite
=================================
The build of the test suite is organized in the following manner:

* The build of all test artifacts is protected by the MK_TESTS knob.
  The user can disable these with the WITHOUT_TESTS setting in
  src.conf(5).

* The goal for /usr/tests/ (the installed test programs) is to follow
  the same hierarchy as /usr/src/ wherever possible, which in turn drives
  several of the design decisions described below.  This simplifies the
  discoverability of tests.  We want a mapping such as:

    /usr/src/bin/cp/      -> /usr/tests/bin/cp/
    /usr/src/lib/libc/    -> /usr/tests/lib/libc/
    /usr/src/usr.bin/cut/ -> /usr/tests/usr.bin/cut/
    ... and many more ...

* Test programs for specific utilities and libraries are located next
  to the source code of such programs.  For example, the tests for the
  src/lib/libcrypt/ library live in src/lib/libcrypt/tests/.  The tests/
  subdirectory is optional and should, in general, be avoided.

* The src/tests/ hierarchy (this directory) provides generic test
  infrastructure and glue code to join all test programs together into
  a single test suite definition.

* The src/tests/ hierarchy also includes cross-functional test programs:
  i.e. test programs that cover more than a single utility or library
  and thus don't fit anywhere else in the tree.  Consider this to follow
  the same rationale as src/share/man/: this directory contains generic
  manual pages while the manual pages that are specific to individual
  tools or libraries live next to the source code.

In order to keep the src/tests/ hierarchy decoupled from the actual test
programs being installed --which is a worthy goal because it simplifies
the addition of new test programs and simplifies the maintenance of the
tree-- the top-level Kyuafile does not know which subdirectories may
exist upfront.  Instead, such Kyuafile automatically detects, at
run-time, which */Kyuafile files exist and uses those directly.

Similarly, every directory in src/ that wants to install a Kyuafile to
just recurse into other subdirectories reuses this Kyuafile with
auto-discovery features.  As an example, take a look at src/lib/tests/
whose sole purpose is to install a Kyuafile into /usr/tests/lib/.
The goal in this specific case is for /usr/tests/lib/ to be generated
entirely from src/lib/.

-- 
$FreeBSD$