The Lsof Test Suite

			    Contents

		A.  Introduction

		    1.  Test Suite Goals

		    2.  Not a FAQ

		    3.  Where have the tests been tested?

		B.  Test Methodology

		    1.  Test Limitations

		    2.  Test Data Base and Scripts

		    3.  The Makefile

			3.1 The CkTestDB Script

		    4.  The Lsof Executable and LT_LSOF_PATH

		    5.  Automated Testing

		C.  Configure Script Participation

		    1.  config.cc

		    2.  config.cflags

			2.1  config.cflags Contents

		    3.  config.ldflags

		    4.  config.xobj

		D.  Cleaning -- Quick or Spotless

		E.  Test Libraries

		    1.  LTlib.c

		F.  The Individual Tests

		    1.  LTbasic, a Basic Lsof Test

		    2.  LTbigf, Test Sizes and Offsets for Large

			(> 32 bit) Files

		    3.  LTdnlc, Test the Kernel's Dynamic Name Lookup

		        Cache

		    4.  LTlock, Lock Tests

		    5.  LTnfs, NFS Test

		    6.  LTnlink, Link Count Test

		    7.  LTsock, Test IPv4 Sockets

		    8.  LTszoff, Test Sizes and Offsets for Small

			(< 32 bit) Files

		    9.  LTunix, Test UNIX Domain Sockets

		Appendix A, Test Files

		Appendix B, Test Validations

		Appendix C, Test Failures

A. Introduction

===============

Lsof has an automated test suite whose components are located in

the tests/ sub-directory of the lsof top-level directory.  Configuring,

building and testing lsof can be done with these shell commands:

    $ Configure -n <dialect-abbreviation>

    $ make

    $ cd tests

    $ make

That's all there is to it!

But read on for more dirty details.

A.1. Test Suite Goals

=====================

The lsof test suite attempts to test basic lsof features.  It does

not promise to test every lsof feature for every supported dialect.

(That's a nearly impossible goal.)

As a result, the test suite cannot promise that every lsof feature

works as documented.  At best the test suite gives some assurance

that basic, standard and some optional lsof features work.

A.2. Not a FAQ

==============

One caution: this is not a frequently asked questions (FAQ) file

for the lsof test suite.  FAQs on the lsof test suite will be found

in the one and only lsof FAQ in file 00FAQ of the lsof distribution,

or on-line at:

    ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ

A.3. Where have the tests been tested?

======================================

OK, I just said this isn't an FAQ and here comes a question and

answer that looks like an FAQ.  Consider it a very frequently asked

question and indulge me -- let me answer it here.

The lsof test suite hasn't been tested everywhere it might be

possible to build lsof successfully.  That "everywhere" includes

dialect versions -- e.g., Solaris < 2.6 -- to which I no longer

have access.  On some dialect versions to which I have access, some

tests won't run because the test system lacks support.

In "Appendix B, Test Validations" I've tried to list where I compiled

and tested the test suite and information on any tests I was unable

to run.  In "Appendix C, Test Failures" I list where the test suite

fails and why it failed.

A.4 Where are the tests?

========================

This is another FAQ whose answer is that the tests are in the tests/

sub-directory of the main lsof source directory.

B. Test Methodology

===================

The test suite is made up of individual C programs.  Test setup is

performed by the lsof Configure script itself, which writes a set

of dialect configuration files in the tests/ subdirectory.  (See

"C. Configure Script Participation.")

Each program or script performs a specialized tests.  Those tests

are described below in "F. The Individual Tests".

Each test measures lsof functionality by putting a specific lsof

command execution at the end of an in-bound (to the test) pipe.

The caller asks lsof to write its results to the pipe in field

output form.  (See the -F option in the lsof man page.)

Using an in-bound lsof pipe allows the tests to measure a great

deal of lsof functionality, including as an interesting side effect,

the performance of field output.  Consequently, there's no special

field output test.

B.1. Test Limitations

=====================

One limitation of the tests is that they don't measure lsof formatted

output -- i.e., the output normally see when lsof is run.  There

are just too many variants of lsof output produced across the range

of dialects where lsof runs, so field output is a more consistent

way to process lsof output.

But using field output does mean that the test suite doesn't check

for lsof formatting problems, except in the field output itself.

B.2. Test Data Base and Scripts

===============================

The TestDB file contains a simple data base that describes where

the tests have been validated.  Entries are formed from a combination

of the lines in the config.cflags file produced by the lsof Configure

script.  The entries can be considered "lsof dialect footprints,"

hereafter simply called "dialect footprints" or just "footprints."

Two shell scripts support TestDB.  The first, Add2TestDB, will add

a footprint to TestDB.  I don't recommend you use this script.

Mostly it's for my use when I find that the test suite has been

validated on a new dialect.

It's also possible to add a footprint to TestDB by simply editing

TestDB and pasting into it a copy of the footprint reported by a

failed Makefile rule.  I don't generally recommend this be done,

either.

There are Makefile rules that use (and avoid) the CkTestDB script.

(See "B.3 The Makefile".)

The default (i.e., "all") Makefile rule uses the CkTestDB script

to look for the footprint in TestDB. If no footprint is found, the

script issues a warning, displays the unfound footprint, and asks

if running the test suite should continue.

The "auto" Makefile rule also uses CkTestDB, but with a special

call that causes CkTestDB to look in TestDB for the footprint,

report it when it can't be found, and then fail.  That CkTestDB

failure causes the "auto" rule to fail, too.

The "silent" Makefile rule doesn't use CkTestDB to look in TestDB

for the footprint.  It runs the standard and basic tests as silently

as possible, then returns a failure or success exit code that

signals the result of the running of the tests.  (Use the "silent"

rule carefully, because it will skip proving the tests have previously

run on the dialect.)

B.3. The Makefile

=======================

The Makefile runs the tests in the test suite.  It has these rules.

    all         runs the basic test and the standard tests,

		interacting with the caller should the footprint

		not be found in TestDB.

		(This is the default rule.)

    auto        runs the basic test and the standard tests on a

		previously validated system as silently as possible.

		The footprint must be found in TestDB for this rule

		to succeed.  (See the "silent" rule for one that

		avoids checking TestDB.)

		This rule is designed for lsof build scripts that

		want a quick noiseless test to make sure what they

		built works as it previously did.

		This rule calls CkTestDB in a way that inhibits

		its normal go-ahead request. (See "B.2.1 The CkTestDB

		Script".)  If CkTestDB finds the footprint and all

		tests succeed, this rule returns a zero exit code

		(success).  If the footprint isn't found or if any

		test fails, a non-zero exit code (failure) is

		returned.

    ckDB        calls the CkTestDB script to look for a footprint.

		If none is found, the way CkTestDB was called (See

		"B.3.1 The CkTestDB Script".) causes it to return

		a non-zero exit code (failure) to this rule, and

		the rule then returns a non-zero exit code (failure)

		itself.

		This rule is used by the "auto" rule.  If this rule

		succeeds (zero exit code), the "auto" rule then

		uses the "silent" rule.

    clean       removes test and compiler output.  (See the "D.

		Cleaning -- Quick or Spotless" section.)

    opt		runs the optional tests.

    optional

    silent      runs the lsof basic and standard tests as silently

		as possible (as the "auto" rule does), but without

		using CkTestDB to look for a footprint.  If all

		tests succeed, the rule returns a zero exit code

		(success).  If any test fails, the rule returns a

		non-zero exit code (failure).

		Use the "silent" rule carefully, because it will

		skip proving the tests have previously run on the

		dialect.

    spotless    does what the clean rule does and also removes the

		config.* files created by ../Configure.  (See the

		"D. Cleaning -- Quick or Spotless" section.)

    std		runs the basic test and the standard tests.

    standard

The Makefile cleaning rules are further described in "D.  Cleaning

-- Quick or Spotless."

B.3.1 The CkTestDB Script

=========================

Some Makefile rules (e.g., "all" and "auto") use the CkTestDB script

to make sure the tests have been run previously on the dialect.

CkTestDB does that by looking for the dialect's footprint in TestDB.

If no footprint is found, and if standard input is a TTY, CkTestDB

asks for a go-ahead signal.  If standard input isn't a TTY, CkTestDB

aborts the test run.  (See "B.2. Test Data Base and Scripts".)

The Makefile "silent" rule does not call CkTestDB.  use the "silent"

rule carefully, because it will skip proving the tests have previously

run on the dialect.

B.4. The Lsof Executable and LT_LSOF_PATH

=========================================

Normally the programs in the test suite use the lsof executable in

their parent directory, ../lsof.  Usually that lsof has just been

built and testing it is the next logical step.

Be careful that ../lsof has sufficient permission to access the

necessary kernel resources -- e.g., /dev/kmem, /dev/mem, /proc,

etc.  If it doesn't the tests will fail.  (The tests do check to

see if they can open /dev/mem and /dev/kmem for read access if

LT_KMEM is defined in config.cflags and if the path to the lsof

executable is ../lsof.)

Here are two possible ways you can make sure the lsof being tested

has sufficient permission: 1) use chmod and chgrp to enable its

running and put its path in LT_LSOF_PATH, thus disabling the check

in the tests for kernel memory access; or 2) run the tests (and

hence the lsof being tested) under a login that has sufficient

permission -- e.g., is in a group that can read /dev/kmem.

You can direct the tests to use a different lsof executable by

specifying its path in the LT_LSOF_PATH environment variable.  To

test an lsof executable already installed in /usr/local/etc --

provided that lsof is at revision 4.63 or higher -- do this:

    $ LT_LSOF_PATH=/usr/local/etc/lsof

    $ export LT_LSOF_PATH

    $ cd .../lsof_<version>/tests

    $ make

When you specify an alternate executable path via LT_LSOF_PATH,

that also prevents the tests from checking to see if they have

kernel memory access.

B.5 Automated Testing

=====================

Normally the lsof test suite is wordy and may require interaction.

When you want to avoid those interferences, use the Makefile "auto"

or "silent" rules.  (See the description of the "auto" and "silent"

rules in "B.3 The Makefile".)

The footprint must be present in TestDB in order to use the "auto"

rule.  If it is not, the "auto" rule will fail and report the

missing footprint.  Footprints in TestDB proclaim that the tests

have previously succeeded on the dialect.

The footprint need not be present in TestDB in order to use the

"silent" rule.  Use the "silent" rule carefully, because it will

skip proving the tests have previously run on the dialect.

C. Configure Script Participation

=================================

An important step in setting up the test suite is performed by the

Configure script in the lsof home directory (the parent to tests/.)

Configure writes four files in tests/ that describe how the tests

are to be compiled, configured and loaded.  The files also describe

options that Configure selected that are important to the test

suite.

C.1. config.cc

==============

This file, config.cc, contains the name of or the path to the C

compiler used to compile lsof.  The Makefile uses this file in

place of the standard make(1) CC string with a shell in-place

execution statement -- i.e., `cat config.cc`.

If the LSOF_CC environment variable is supplied to the lsof Configure

script, its value will appear in the config.cc file.

C.2. config.cflags

==================

This file, config.cflags, contains C compiler flags that Makefile

uses to compile the C programs in the test suite.  As with the

compiler file, config.cc, the make rules incorporate the contents

of this file into C compiler options with `cat config.cflags`.

This file is also used by the Add2TestDB and CkTestDB shell scripts

to build and match footprints.  (See "B.2. Test Data Base and

Scripts.")

C.2.1 config.cflags Contents

============================

The config.cflags file may contain the following C compiler flags.

    -DLT_AIXA               is present if lsof was built for AIX.

			    It contains the AIX architecture flag.

			    (See the lsof Configure script or

			    dialects/aix/dlsof.h for more information

			    on the AIX architecture flag.)

    -DLT_BIGF		    is present if lsof was built for a dialect

			    that has large file (sizes and offsets >

			    32 bits).

    -DLT_CC		    is present if the lsof compiler is cc.

    -DLT_DEV64		    is present if the FreeBSD dialect uses a 64

			    devite type.

    -DLT_DIAL_	    always ends in (the  part) the

			    "canonical" -- i.e., usually the most

			    common abbreviation by which the dialect

			    is known.

			    Example: -DLT_DIAL_solaris

    -DLT_GCC		    is present if the lsof compiler is gcc.

    -DLT_K64		    is present if lsof has been built for a

			    64 bit kernel

    -DLT_KMEM		    is present if lsof has been built to

			    use /dev/kmem to obtain kernel values.

    -DLT_VERS=<vn>	    contains the version number for the

			    dialect, as used in lsof pre-processor

			    tests.

			    Example for Solaris 10: -DLT_VERS=100000

    -DLT_VPATH		    is present if the dialect has the v_path

			    member in the vnode structure (e.g., some

			    versions of Solaris 10).

The config.cflags file may also contain dialect-specific compiler

flags needed to activate a specific feature on the dialect.  For

example, for HP-UX config.cflags might contain:

    -D_LARGEFILE64_SOURCE   This compiler flag enables the use of

			    large-file system library functions

			    --e.g., open64().

			    The lsof Configure script stanzas for

			    the dialects select these options.

C.3. config.ldflags

===================

This file, config.ldflags, contains the dialect loader flags --

i.e., the equivalent to make(1) LFLAGS -- for loading the test

programs.

Example for Solaris: -lsocket           this adds the socket library

					to the loading of the lsof

					test programs.

Example for UnixWare: -lsocket -lnsl    this adds the socket and

					name server libraries to

					the loading of the lsof

					test programs.

C.4. config.xobj

================

This file, config.xobj, contains the paths to any extra object

files (.o's) that must be loaded when the test suite C programs

are loaded.  Like config.cc and config.cflags, it's incorporated

into the loader statements of the Makefile's rules with `cat

config.xobj`.

Examples for DEC OSF/1 and NEXTSTEP:

    ../lib/snpf.o       this loads the private lsof object file

			that contains an snprintf() function.  (The

			DEC OSF/1 4.0 and NEXTSTEP 3.1 C libraries

			don't have snprintf().)

D. Cleaning -- Quick or Spotless

================================

There are two Makefile rules that clean the tests/ subdirectory --

"clean" and "spotless".  They cause different degrees of cleaning.

    clean       a "quick" clean that removes compiled object files,

		executables and test files.  It does NOT remove

		the configuration files that ../Configure and the

		config.perl rule wrote.

    spotless    cleans out everything clean does -- plus the

		configuration files that ../Configure and the

		config.perl rule wrote.

		This is the rule used when `./Configure -clean` is

		specified.  If this rule is used, `../Configure -n

		` and `../make`) must be run again before

		the test suite can be used.

E. Test Library

===============

The lsof test suite provides a C library.

E.1. LTlib.c

============

This is a C library of common functions used by tests.  Configured

at compile time by the contents of config.cflags, it uses the single

header file LsofTest.h.  LsofTest.h tailors its definitions to the

dialect at compile time, using the LT_DIAL_* definitions in

config.cflags.

Two particularly useful functions in the library are: ExecLsof(),

which will execute an lsof child process; and RdFromLsof(), which

will read from the in-bound lsof pipe, and decode the fields into

structures that are easy for C programs to process.

This library is a good model for processing field output in a C

program from an in-bound lsof pipe.

The source for the library, LTlib.c, contains more documentation.

F. The Individual Tests

=======================

The individual tests are listed in this section.  The listings

explain what the tests do, a few errors they might report, and how

to use options and environment variables to customize the tests.

The test descriptions are listed in this section in alphabetical

order, not in the order they are run by Makefile.

The Makefile runs the tests in three groups, basic tests, standard

tests, and optional tests.  The default make "all" rule runs the

basic and standard tests.  (The "standard", "std", and "test"

Makefile rules are synonyms to "all".) If the standard tests succeed,

Makefile suggests running the optional tests with the "opt" (or

"optional") rule.

The Makefile "auto" and "silent" rules run only the basic and

standard tests.  They do not run or suggest you run the optional

tests.

    The basic test:

	LTbasic

    Standard tests:

	LTnlink

	LTsock

	LTszoff

	LTunix

    Optional tests:

	LTbigf

	LTdnlc

	LTlock

	LTnfs

The basic and standard tests should all succeed on all dialects,

although LTnlink may warn that it can't perform its unlink test on

an NFS file system.

The optional tests may run, they may be disabled for specific

dialects, or they may fail because of special resource needs --

e.g., LTbigf will run only on UNIX dialects where it knows how to

handle files whose lengths exceed 32 bits, and LTnfs needs access

to an NFS file system mounted from a remote NFS server.

Tests that need special resources usually provide a hint about the

resources when they fail.  Information about special resource needs

may also be found in the following sections about the individual

tests.

G.1. LTbasic, a Basic Lsof Test

===============================

This is the basic lsof test.  If it doesn't run, it's not likely

any other tests will run, either.  Hence, if it fails, no Makefile

rule runs any other tests.

This test uses lsof to locate files in the lsof process, including

current working directory, the lsof executable, and the /dev/kmem

open file.

Finding the lsof executable may not be possible on AIX if lsof was

compiled without support for its -X option.

Finding /dev/kmem use by lsof is only possible on dialects where

lsof uses /dev/kmem.  The -DLT_KMEM define indicates that.

Run this test:

    $ ./LTbasic

Environment variables: LT_LSOF_PATH defines the path to the lsof

		       executable.  (The default is ../lsof.)

G.2. LTbigf, Test Sizes and Offsets for Large (> 32 bit) Files

==============================================================

This is a test in the optional test group.

This test is effective only when ../Configure has put -DLT_BIGF in

config.cflags.  Without that definition this test simply reports

that the dialect doesn't support large files.  That report is

accompanied by a successful test exit code, so that the runner of

the test (e.g., the Makefile) won't believe the test failed.

When a dialect does support large files, the test attempts to create

a file that looks very large -- e.g., has a length as reported by

ls(1) of 0x140000000 bytes.  However, the file really has only a

small amount of data in it, the rest of the file consists of a

large standard UNIX file system "hole."

By default the test file is named config.LTbigf<PID>, where PID is

the Process ID of the LTbigf process.

When that file is not on a file system enabled for large files, or

when the process that runs LTbigf can't create a big file, LTbigf

will report an error.  The error will be accompanied by hints that

the -p option may need to be used to define a path where the test

can write a large file, or the process ulimit file block size may

need to be raised -- e.g., to "unlimited."

LTbigf can't test file offset reporting on Linux kernels below

2.6.22, because the /proc file systems of those kernels don't make

file offsets available to lsof.

Run this test:

    $ ./LTbigf [-p <path>]

Environment variables: LT_LSOF_PATH defines the path to the lsof

		       executable.  (The default is ../lsof.)

G.3. LTdnlc, Test the Kernel's Dynamic Name Lookup Cache

========================================================

This is a test in the optional test group.

This test asks lsof to locate the current working directory of its

own process and report the path it has assembled from the components

it found in the kernel's Dynamic Name Lookup Cache (DNLC) or via

other dialect-specific methods.  (E.g., Linux, HP-UX 11.11, and

some Tru64 UNIX versions have private name lookup methods.)

The test checks what lsof reports as the current working directory

path for any missing components and counts the number of full paths

returned.  (Symbolic link complications prevent testing for exact

path matches.)  The test is repeated.  If full paths are returned

at least half the time, the test considers itself successful.

This test can't be run on AIX, because lsof can't access the DNLC

there.  It can't be run on Apple Darwin versions below 8.0, either,

because insufficiently reliable DNLC information is available there.

This test may fail on other dialects when the file system -- e.g., NFS.

/tmp, loopback -- doesn't fully participate in the dialect's DNLC.

Run this test:

    $ ./LTdnlc

Environment variables: LT_LSOF_PATH defines the path to the lsof

		       executable.  (The default is ../lsof.)

G.4. LTlock, Lock Tests

=======================

This is a test in the optional test group.

This test uses flock() and fcntl() to set and clear file locks,

and measures lsof's ability to report them.  The choice of system

lock call is based on the dialect.  (There are LT_DIAL_* pre-processor

tests in LTlock.c.)

This test can't be run on an NFS client file system, because NFS

lock information is kept on the server.  Lsof on the client can't

see that server kernel data.

By default the test attempts to create a file named config.LTlock<PID>,

where PID is the Process ID of the locking test process.  It uses

lsof to determine if the file is on a client NFS file system.  If

it is, the test aborts, hinting that the -p option can be used to

specify a non-client-NFS test file path.

This test can't be run on Darwin, because insufficient file system

lock information is available to lsof there.

Run this test:

    $ ./LTlock [-p <path>]

Environment variables: LT_LSOF_PATH defines the path to the lsof

		       executable.  (The default is ../lsof.)

G.6. LTnfs, NFS Test

====================

This is a test in the optional test group.

This test verifies that lsof can locate files mounted on a client

NFS system from an NFS server.

By default it creates a test file, config.LTnfs<PID>, where PID is

the Process ID of the test process.  The test then uses lsof to

find the file on an NFS file system.

If lsof can't find the file the test warns that the test file might

not be on an NFS file system and hints that the -p option may be

used to specify the path of an NFS file, provided the test can have

read access to it there.  The test warning also states that the

file at the path specified with -p must be a regular file, not a

directory.

This test can't be run on Darwin versions below 8.0, because

insufficient NFS file information is available to lsof there.

Run this test:

    $ ./LTnfs [-p <path>]

Environment variables: LT_LSOF_PATH defines the path to the lsof

		       executable.  (The default is ../lsof.)

G.7. LTnlink, Link Count Test

=============================

This is a test in the standard test group.

The test checks lsof's reporting of link count (nlink in UNIX

argot.)

It creates a test file in the current working directory named

config.LTnlink<PID>, where  PID is the Process ID of the test

process.  It then uses stat(2) and lsof to measure the link count

of the file.

If LTnlink creates the test file in the current working directory

and it is on an NFS file system, LTnlink won't be able to perform

one section of its test.  In that section the test file is unlinked

so its link count will be zero and lsof is asked to find it among

the set of files whose link counts are zero.

When an NFS file is unlinked its link count isn't reduced until

the last open instance is closed on either the NFS clients or the

NFS.  That's a consequence of NFS statelessness and leads to the

occasional presence of files with names of the form .nfsxxxx.

Should LTnlink find its test file on an NFS file system, it disables

the unlink section of its tests and issues a warning.  It also

issues a hint that the test file path can be named via the -p option

to give a test file location that isn't on an NFS file system.

This test can't be run on Darwin, because insufficient file system link

count information is available to lsof there.

Because some UNIX dialects delay the reporting of a link count

update after a file has been unlinked, LTnlink may not get its

expected response from lsof for a while after the test file has

been unlinked.  In that cause LTnlink may delay for up to a minute,

calling lsof once every two seconds and displaying a "waiting for

link count update: ..." message.

Some file systems -- e.g., ZFS on Solaris 11 -- don't allow LTnlink to

unlink its test file, because LTnlink has the file open.  LTnlink

explains that failure and suggests that it be run with path of the "-p

path" option set to a file on /tmp.  See 00FAQ for more information.

Run this test:

    $ ./LTnlink [-p <path>]

Environment variables: LT_LSOF_PATH defines the path to the lsof

		       executable.  (The default is ../lsof.)

G.7. LTsock, Test IPv4 Sockets

==============================

This is a test in the standard test group.

This test uses lsof to locate open IPv4 socket files that the test

has created itself.  The test opens a server socket, then forks a

child process to connect to that socket.  After both are running,

the test uses lsof to find the open socket files at their known

host and port addresses.

Run this test:

    $ ./LTsock

Environment variables: LT_LSOF_PATH defines the path to the lsof

		       executable.  (The default is ../lsof.)

G.8. LTszoff, Test Sizes and Offsets for Small (< 32 bit) Files

===============================================================

This is a test in the standard test group.

This test checks lsof's reporting of file size and offset for small

(< 32 bits) files.

It creates a test file in the current working directory named

config.LTszoff<PID>.  PID is the Process ID of the test process.

LTszoff can't test file offset reporting on Linux kernels below

2.6.22, because the /proc file systems of those kernels don't make

file offsets available to lsof.

Run this test:

    $ ./LTszoff [-p <path>]

Environment variables: LT_LSOF_PATH defines the path to the lsof

		       executable.  (The default is ../lsof.)

G.9.  LTunix, Test UNIX Domain Sockets

======================================

This is a test in the standard test group.

This test checks lsof's reporting of UNIX domain sockets.

The test creates a pair of UNIX domain sockets and uses bind(2) to

associate the file system names config.LT0U<PID> (client) and

config.LT1U<PID> (server) with them.  (PID is the test process ID.)

The test then uses lsof to find the two open UNIX domain socket

files.

Run this test:

    $ ./LTunix

Environment variables: LT_LSOF_PATH defines the path to the lsof

		       executable.  (The default is ../lsof.)

Appendix A, Test Files

======================

These files may be created by suite tests.

			Created

    ./tests Name	by Test	    Use

    ============	=======	    ===

    config.LTbifg**     LTbigf      to test lsof's large file size

				    and offset reporting

    config.LTlock*	LTlock	    for locking tests

    config.LTnfs*	LTnfs	    for NFS tests

    config.LTnlink*	LTnlink	    for link count tests

    config.LTszoff*     LTszoff     for small file size and and

				    offset reporting

    config.LT[01]U*     LTunix      two UNIX domain sockets, used

				    to determine if lsof can report

				    their open instances properly

Appendix B, Test Validations

============================

This appendix lists the UNIX dialects and their versions where I

have validated the test suite.  The list indicates the particular

tests I was unable to run, mostly LTnfs because the test systems

I used had no NFS file systems mounted.

The information in the following table is encoded in a test data

base file, TestDB, as footprints, using the tests compiler options

written to config.cflags by the lsof Configure script.  See "B.2.

Test Data Base and Scripts" for more information on the test data

base, footprints, and the scripts that support them.

    UNIX

    Dialect	  Dialect Description		Untested Tests

    ======= 	  ===================		==============

    AIX		  4.3.3, Power, cc

		  5.1, Power-32, cc

		  5.1, Power-32, gcc

		  5.1, Power-64, cc

		  5.2, Power-32, cc

		  5.2, Power-32, gcc

		  5.2, Power-64, cc

		  5.2, Power-64, gcc

		  5.3, Power-64, cc

    Darwin        1.4, 5.5, 6.x, 7.x gcc	Darwin lsof doesn't

						have adequate support

						to allow the LTbigf,

						Ltdnlc, LTlock, LTnfs,

						and LTnlink tests to

						run.

		  8.0, gcc			Darwin lsof doesn't

						have adequate support

						to allow the LTbigf,

						LTlock and LTnlink

						tests to run.

		  9.0, gcc			Darwin lsof doesn't

						have adequate support

						to allow the LTlock

						test to run.

		  10.0, gcc			Darwin lsof doesn't

						have adequate support

						to allow the LTlock test

						to run.

		  11.0, gcc			Darwin lsof doesn't

						have adequate support

						to allow the LTlock test

						to run.

    FreeBSD       4.5, i386, gcc

		  4.6, i386, gcc

		  4.7, i386, gcc

		  4.8, i386, gcc

		  4.9, i386, gcc