Go to file
Brian Behlendorf b7dc313837 Add Thread Specific Data (TSD) Regression Test
To validate the correct behavior of the TSD interfaces it's
important that we add a regression test.  This test is designed
to minimally exercise the fundamental TSD behavior, it does not
attempt to validate all potential corner cases.

The test will first create 32 keys via tsd_create() and register
a common destructor.  Next 16 wait threads will be created each
of which set/verify a random value for all 32 keys, then block
waiting to be released by the control thread.  Meanwhile the
control thread verifies that none of the destructors have been
run prematurely.

The next phase of the test is to create 16 exit threads which
set/verify a random value for all 32 keys.  They then immediately
exit.  This is is designed to verify tsd_exit() which will be
called via thread_exit().  This must result in all registered
destructors being run and the memory for the tsd being free'd.

After this tsd_destroy() is verified by destroying all 32 keys.
Once again we must see the expected number of destructors run
and the tsd memory free'd.  At this point the blocked threads
are released and they exit calling tsd_exit() which should do
very little since all the tsd has already been destroyed.

If this all goes off without a hitch the test passes.  To ensure
no memory has been leaked, I have manually verified that after
spl module unload no memory is reported leaked.
2010-12-07 10:02:44 -08:00
cmd Support custom build directories 2010-09-05 21:49:05 -07:00
config Refresh autogen.sh products 2010-11-30 10:36:58 -08:00
include Add Thread Specific Data (TSD) Implementation 2010-12-07 10:02:32 -08:00
lib Support custom build directories 2010-09-05 21:49:05 -07:00
module Add Thread Specific Data (TSD) Regression Test 2010-12-07 10:02:44 -08:00
patches Reimplement rwlocks for Linux lock profiling/analysis. 2009-09-18 16:09:47 -07:00
scripts Support custom build directories 2010-09-05 21:49:05 -07:00
.gitignore Ignore unsigned module build products 2010-03-11 14:29:17 -08:00
AUTHORS Public Release Prep 2010-05-17 15:18:00 -07:00
autogen.sh Public Release Prep 2010-05-17 15:18:00 -07:00
ChangeLog Prep for spl-0.5.0 tag 2010-08-13 09:33:50 -07:00
configure Refresh autogen.sh products 2010-11-30 10:36:58 -08:00
configure.ac Support custom build directories 2010-09-05 21:49:05 -07:00
COPYING Public Release Prep 2010-05-17 15:18:00 -07:00
DISCLAIMER Public Release Prep 2010-05-17 15:18:00 -07:00
INSTALL Public Release Prep 2010-05-17 15:18:00 -07:00
Makefile.am Support custom build directories 2010-09-05 21:49:05 -07:00
Makefile.in Support custom build directories 2010-09-05 21:49:05 -07:00
META Prep for 0.5.2 tag 2010-11-05 11:52:46 -07:00
README.markdown Fix markdown rendering 2010-09-15 09:05:34 -07:00
spl_config.h.in Linux 2.6.36 compat, fs_struct->lock type change 2010-11-09 13:29:47 -08:00
spl-modules.spec.in Minor spec file cleanup for RHEL6 package dependency. 2010-05-21 11:53:49 -07:00
spl.spec.in Remove usage of the __id_u macro for portability. 2009-10-05 12:51:58 -07:00

The Solaris Porting Layer (SPL) is a Linux kernel module which provides many of the Solaris kernel APIs. This shim layer makes it possible to run Solaris kernel code in the Linux kernel with relatively minimal modification. This can be particularly useful when you want to track upstream Solaris development closely and dont want the overhead of maintaining a large patch which converts Solaris primitives to Linux primitives.

To build packages for your distribution:

$ ./configure
$ make pkg

Full documentation for building, configuring, and using the SPL can be found at: http://zfsonlinux.org