Guide to Porting lsof 4 to Unix OS Dialects

**********************************************************************

| The latest release of lsof is always available via anonymous ftp   |

| from lsof.itap.purdue.edu.  Look in pub/lsof.README for its        |

| location.                                                          |

**********************************************************************

			    Contents

	How Lsof Works

	/proc-based Linux Lsof -- a Different Approach

	General Guidelines

	Organization

	Source File Naming Conventions

	Coding Philosophies

	Data Requirements

	Dlsof.h and #include's

	Definitions That Affect Compilation

	Options: Common and Special

	Defining Dialect-Specific Symbols and Global Storage

	Coding Dialect-specific Functions

	Function Prototype Definitions and the _PROTOTYPE Macro

	The Makefile

	The Mksrc Shell Script

	The MkKernOpts Shell Script

	Testing and the lsof Test Suite

	Where Next?

How Lsof Works

--------------

Before getting on with porting guidelines, just a word or two about

how lsof works.

Lsof obtains data about open UNIX dialect files by reading the

kernel's proc structure information, following it to the related

user structure, then reading the open file structures stored

(usually) in the user structure.  Typically lsof uses the kernel

memory devices, /dev/kmem, /dev/mem, etc. to read kernel data.

Lsof stores information from the proc and user structures in an

internal, local proc structure table.  It then processes the open

file structures by reading the file system nodes that lie behind

them, extracting and storing relevant data in internal local file

structures that are linked to the internal local process structure.

Once all data has been gathered, lsof reports it from its internal,

local tables.

There are a few variants on this subject.  Some systems don't have

just proc structures, but have task structures, too, (e.g., NeXTSTEP

and OSF/1 derivatives).  For some dialects lsof gets proc structures

or process information (See "/proc-based Linux Lsof -- a Different

Approach) from files of the /proc file system.  It's not necessary

for lsof to read user structures on some systems (recent versions

of HP-UX), because the data lsof needs can be found in the task or

proc structures.  In the end lsof gathers the same data, just from

slightly different sources.

/proc-based Linux Lsof -- a Different Approach

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

For a completely different approach to lsof construction, take a

look at the /proc-based Linux sources in .../dialects/linux/proc.

(The sources in .../dialects/linux/kmem are for a traditional lsof

that uses /dev/kmem to read information from kernel structures.)

The /proc-based lsof obtains all its information from the Linux

/proc file system.  Consequently, it is relatively immune to changes

in Linux kernel structures and doesn't need to be re-compiled each

time the Linux kernel version changes.

There are some down-sides to the Linux /proc-based lsof:

    *  It must run setuid-root in order to be able to read the

       /proc file system branches for all processes.  In contrast,

       the /dev/kmem-based Linux lsof usually needs only setgid

       permission.

    *  It depends on the exact character format of /proc files, so

       it is sensitive to changes in /proc file composition.

    *  It is limited to the information a /proc file system

       implementor decides to provide.  For example, if a

       /proc/net/<protocol> file lacks an inode number, the

       /proc-based lsof can't connect open socket files to that

       protocol.  Another deficiency is that the /proc-based may

       not be able to report file offset (position) information,

       when it isn't available in the /proc/<PID>/fd/ entry for a

       file.

       In contrast the /dev/kmem-based lsof has full access to

       kernel structures and "sees" new data as soon as it appears.

       Of course, that new data requires that lsof be recompiled

       and usually also requires changes to lsof.

Overall the switch from a /dev/kmem base to a /proc one is an

advantage to Linux lsof.  The switch was made at lsof revision 4.23

for Linux kernel versions 2.1.72 (approximately) and higher.  The

reason I'm not certain at which Linux kernel version a /proc-based

lsof becomes possible is that the /proc additions needed to implement

it have been added gradually to Linux 2.1.x in ways that I cannot

measure.

/proc-based lsof functions in many ways the same as /dev/kmem-based

lsof.  It scans the /proc directory, looking for <PID>/ subdirectories.

Inside each one it collects process-related data from the cwd, exe,

maps, root, and stat information files.

It collects open file information from the fd/ subdirectory of each

<PID>/ subdirectory.  The lstat(2), readlink(2), and stat(2) system

calls gather information about the files from the kernel.

Lock information comes from /proc/locks.  It is matched to open

files by inode number.  Mount information comes from /proc/mounts.

Per domain protocol information comes from the files of /proc/net;

it's matched to open socket files by inode number.

The Linux /proc file system implementors have done an amazing job

of providing the information lsof needs.  The /proc-based lsof

project has so far generated only two kernel modification:

    *  A modification to /usr/src/linux/net/ipx/af_ipx.c adds the

       inode number to the entries of /proc/net/ipx.

       Jonathan Sergent did this kernel modification.

       It may be found in the .../dialects/linux/proc/patches

       subdirectory of the lsof distribution.

    *  An experimental modification to /usr/src/linux/fs/stat.c

       allows lstat(2) to return file position information for

       /proc/<PID>/fd/<FD> files.

       Contact me for this modification.

One final note about the /proc-based Linux lsof: it doesn't need

any functions from the lsof library in the lib/ subdirectory.

General Guidelines

------------------

These are the general guidelines for porting lsof 4 to a new Unix

dialect:

    *  Understand the organization of the lsof sources and the

       philosophies that guide their coding.

    *  Understand the data requirements and determine the methods

       of locating the necessary data in the new dialect's kernel.

    *  Pick a name for the subdirectory in lsof4/dialects for your

       dialect.  Generally I use a vendor operating system name

       abbreviation.

    *  Locate the necessary header files and #include them in the

       dialect's dlsof.h file.  (You may not be able to complete

       this step until you have coded all dialect-specific functions.)

    *  Determine the optional library functions of lsof to be used

       and set their definitions in the dialect's machine.h file.

    *  Define the dialect's specific symbols and global storage

       in the dialect's dlsof.h and dstore.c files.

    *  Code the dialect-specific functions in the appropriate

       source files of the dialect's subdirectory.

       Include the necessary prototype definitions of the dialect-

       specific functions in the dproto.h file in the dialect's

       subdirectory.

    *  Define the dialect's Makefile and source construction shell

       script, Mksrc.

    *  If there are #define's that affect how kernel structures

       are organized, and those #define's are needed when compiling

       lsof, build a MkKernOpts shell script to locate the #define's

       and supply them to the Configure shell script.

Organization

------------

The code in a dialect-specific version of lsof comes from three

sources:

    1)  functions common to all versions, located in the top level

	directory, lsof4;

    2)  functions specific to the dialect, located in the dialect's

	subdirectory -- e.g., lsof4/dialects/sun;

    3)  functions that are common to several dialects, although

	not to all, organized in a library, liblsof.a.  The functions

	in the library source can be selected and customized with

	definitions in the dialect machine.h header files.

The tree looks like this:

			    lsof4 ----------------------+ 3) library --

			    |   \			     lsof4/lib

  1) fully common functions +    \

      e.g., lsof4/main.c	  + lsof4/dialects/

			   / / / / \

			   + + + +  +

  2) dialect-specific subdirectories -- e.g., lsof4/dialects/sun

The code for a dialect-specific version is constructed from these

three sources by the Configure shell script in the top level lsof4

directory and definitions in the dialect machine.h header files.

Configure uses the Mksrc shell script in each dialect's subdirectory,

and may use an optional MkKernOpts shell script in selected dialect

subdirectories.

Configure calls the Mksrc shell script in each dialect's subdirectory

to assemble the dialect-specific sources in the main lsof directory.

Configure may call MkKernOpts to determine kernel compile-time

options that are needed for compiling kernel structures correctly

for use by lsof.  Configure puts the options in a dialect-specific

Makefile it build, using a template in the dialect subdirectory.

The assembly of dialect-specific sources in the main lsof directory

is usually done by creating symbolic links from the top level to

the dialect's subdirectory.  The LSOF_MKC environment variable may

be defined prior to using Configure to change the technique used

to assemble the sources -- most commonly to use cp instead of ln -s.

The Configure script completes the dialect's Makefile by adding

string definitions, including the necessary kernel compile-time

options, to a dialect skeleton Makefile while copying it from the

dialect subdirectory to the top level lsof4 directory.  Optionally

Makefile may call the dialect's MkKernOpts script to add string

definitions.

When the lsof library, lsof4/lib/liblsof.a, is compiled its

functions are selected and customized by #define's in the dialect

machine.h header file.

Source File Naming Conventions

------------------------------

With one exception, dialect-specific source files begin with a

lower case `d' character -- ddev.c, dfile.c, dlsof.h.  The one

exception is the header file that contains dialect-specific

definitions for the optional features of the common functions.

It's called machine.h for historical reasons.

Currently all dialects use almost the same source file names.  One

exception to the rule happens in dialects where there must be

different source files -- e.g., dnode[123].c -- to eliminate node

header file structure element name conflicts.  The source modules

in a few subdirectories are organized that way.

Unusual situations occur for NetBSD and OpenBSD, and for NEXTSTEP

and OPENSTEP.  Each pair of dialects is so close in design that

the same dialect sources from the n+obsd subdirectory serves NetBSD

and OpenBSD; from n+os, NEXTSTEP and OPENSTEP.

These are common files in lsof4/:

    Configure	the configuration script

    Customize	does some customization of the selected lsof

		dialect

    Inventory	takes an inventory of the files in an lsof

		distribution

    version	the version number

    dialects/	the dialects subdirectory

These are the common function source files in lsof4/:

    arg.c	common argument processing functions

    lsof.h	common header file that #include's the dialect-specific

		header files

    main.c	common main function for lsof 4

    misc.c	common miscellaneous functions -- e.g., special versions

		of stat() and readlink()

    node.c	common node reading functions -- readinode(), readvnode()

    print.c	common print support functions

    proc.c	common process and file structure functions

    proto.h	common prototype definitions, including the definition of

		the _PROTOTYPE() macro

    store.c	common global storage version.h	the current lsof version

		number, derived from the file version by the Makefile

    usage.c	functions to display lsof usage panel

These are the dialect-specific files:

    Makefile	the Makefile skeleton

    Mksrc	a shell script that assists the Configure script

		in configuring dialect sources

    MkKernOpts  an optional shell script that identifies kernel

		compile-time options for selected dialects -- e.g.,

		Pyramid DC/OSx and Reliant UNIX

    ddev.c	device support functions -- readdev() -- may be

		eliminated by functions from lsof4/lib/

    dfile.c	file processing functions -- may be eliminated by

		functions from lsof4/lib/

    dlsof.h	dialect-specific header file -- contains #include's

		for system header files and dialect-specific global

		storage declarations

    dmnt.c	mount support functions -- may be eliminated by

		functions from lsof4/lib/

    dnode.c	node processing functions -- e.g., for gnode or vnode

    dnode?.c	additional node processing functions, used when node

		header files have duplicate and conflicting element

		names.

    dproc.c	functions to access, read, examine and cache data about

		dialect-specific process structures -- this file contains

		the dialect-specific "main" function, gather_proc_info()

    dproto.h	dialect-specific prototype declarations

    dsock.c	dialect-specific socket processing functions

    dstore.c	dialect-specific global storage -- e.g., the nlist()

		structure

    machine.h	dialect specific definitions of common function options --

		e.g., a HASINODE definition to activate the readinode()

		function in lsof4/node.c

		The machine.h header file also selects and customizes

		the functions of lsof4/lib/.

These are the lib/ files.  Definitions in the dialect machine.h

header files select and customize the contained functions that are

to be compiled and archived to liblsof.a.

    Makefile.skel	is a skeleton Makefile, used by Configure

			to construct the Makefile for the lsof

			library.

    cvfs.c		completevfs() function

			USE_LIB_COMPLETEVFS selects it.

			CVFS_DEVSAVE, CVFS_NLKSAVE, CVFS_SZSAVE,

			and HASFSINO customize it.

    dvch.c		device cache functions

			HASDCACHE selects them.

			DCACHE_CLONE, DCACHE_CLR, DCACHE_PSEUDO,

			DVCH_CHOWN, DVCH_DEVPATH, DVCH_EXPDEV,

			HASBLKDEV, HASENVDC, HASSYSDC, HASPERSDC,

			HASPERSDCPATH, and NOWARNBLKDEV customize

			them.

    fino.c		find block and character device inode functions

			HASBLKDEV and USE_LIB_FIND_CH_INO select them.

    isfn.c		hashSfile() and is_file_named() functions

			USE_LIB_IS_FILE_NAMED selects it.

    lkud.c		device lookup functions

			HASBLKDEV and USE_LIB_LKUPDEV select them.

    pdvn.c		print device name functions

			HASBLKDEV and USE_LIB_PRINTDEVNAME select them.

    prfp.c		process_file() function

			USE_LIB_PROCESS_FILE selects it.

			FILEPTR, DTYPE_PIPE, HASPIPEFN, DTYPE_GNODE,

			DTYPE_INODE, DTYPE_PORT, DTYPE_VNODE, DTYPE_PTS,

			HASF_VNODE, HASKQUEUE, HASPRIVFILETYPE,

			HASPSXSHM, HASPSXSEM and HASPTSFN customize it.

    ptti.c		print_tcptpi() function

			USE_LIB_PRINT_TCPTPI selects it.

			HASSOOPT, HASSBSTATE, HASSOSTATE, AHSTCPOPT,

			HASTCPTPIQ and HASTCPTPIW customize it.

    rdev.c		readdev() function

			USE_LIB_READDEV selects it.

			DIRTYPE, HASBLKDEV, HASDCACHE, HASDNAMLEN,

			RDEV_EXPDEV, RDEV_STATFN, USE_STAT, and

			WARNDEVACCESS customize it.

    rmnt.c		readmnt() function

			USE_LIB_READMNT selects it.

			HASFSTYPE, MNTSKIP, RMNT_EXPDEV, RMNT_FSTYPE,

			and MOUNTS_FSTYPE customize it.

    rnam.c		BSD format name cache functions

			HASNCACHE and USE_LIB_RNAM select them.

			HASFSINO, NCACHE, NCACHE_NC_CAST, NCACHE_NM,

			NCACHE_NMLEN, NCACHE_NODEADDR, NCACHE_NODEID,

			NCACHE_NO_ROOT, NCACHE_NXT, NCACHE_PARADDR,

			NCACHE_PARID, NCACHE_SZ_CAST, NCHNAMLEN,

			X_NCACHE, and X_NCSIZE, customize them.

    rnch.c		Sun format name cache functions

			HASNCACHE and USE_LIB_RNCH select them.

			ADDR_NCACHE, HASDNLCPTR, HASFSINO, NCACHE_DP,

			NCACHE_NAME, NCACHE_NAMLEN, NCACHE_NEGVN,

			NCACHE_NODEID, NCACHE_NXT, NCACHE_PARID,

			NCACHE_VP, X_NCACHE, and X_NCSIZE, customize

			them.

    snpf.c		Source for the snprintf() family of functions

			USE_LIB_SNPF selects it.

The comments and the source code in these library files give more

information on customization.

Coding Philosophies

-------------------

A few basic philosophies govern the coding of lsof 4 functions:

    *  Use as few #if/#else/#endif constructs as possible, even at

       the cost of nearly-duplicate code.

       When #if/#else/#endif constructs are necessary:

       o  Use the form

		#if	defined(s<symbol>)

	  in preference to

		#ifdef	<symbol>

	  to allow easier addition of tests to the #if.

       o  Indent them to signify their level -- e.g.,

		#if	/* level one */

		# if	/* level two */

		# endif	/* level two */

		#else	/* level one */

		#endif	/* level one */

	o  Use ANSI standard comments on #else and #endif statements.

    *  Document copiously.

    *  Aim for ANSI-C compatibility:

       o  Use function prototypes for all functions, hiding them

	  from compilers that cannot handle them with the _PROTOTYPE()

	  macro.

       o  Use the compiler's ANSI conformance checking wherever

	  possible -- e.g., gcc's -ansi option.

Data Requirements

-----------------

Lsof's strategy in obtaining open file information is to access

the process table via its proc structures, then obtain the associated

user area and open file structures.  The open file structures then

lead lsof to file type specific structures -- cdrnodes, fifonodes,

inodes, gnodes, hsfsnodes, pipenodes, pcnodes, rnodes, snodes,

sockets, tmpnodes, and vnodes.

The specific node structures must yield data about the open files.  The

most important items and device number (raw and cooked) and node

number.  (Lsof uses them to identify files and file systems named as

arguments.)  Link counts and file sizes are important, too, as are the

special characteristics of sockets, pipes, FIFOs, etc.

This means that to begin an lsof port to a new Unix dialect you

must understand how to obtain these structures from the dialect's

kernel.  Look for kernel access functions -- e.g., the AIX readx()

function, Sun and Sun-like kvm_*() functions, or SGI's syssgi()

function.  Look for clues in header files -- e.g. external declarations

and macros.

If you have access to them, look at sources to programs like ps(1),

or the freely available monitor and top programs.  They may give

you important clues on reading proc and user area structures.  An

appeal to readers of dialect-specific news groups may uncover

correspondents who can help.

Careful reading of system header files -- e.g., <sys/proc.h> --

may give hints about how kernel storage is organized.  Look for

global variables declared under a KERNEL or _KERNEL #if.  Run nm(1)

across the kernel image (/vmunix, /unix, etc.) and look for references

to structures of interest.

Even if there are support functions for reading structures, like the

kvm_*() functions, you must still understand how to read data from

kernel memory.  Typically this requires an understanding of the

nlist() function, and how to use /dev/kmem, /dev/mem, and /dev/swap.

Don't overlook the possibility that you may have to use the process

file system -- e.g., /proc.  I try to avoid using /proc when I can,

since it usually requires that lsof have setuid(root) permission

to read the individual /proc "files".

Once you can access kernel structures, you must understand how

they're connected.  You must answer questions like:

    *  How big are kernel addresses?  How are they type cast?

    *  How are kernel variable names converted to addresses?

       Nlist()?

    *  How are the proc structures organized?  Is it a static

       table?  Are the proc structures linked?  Is there a

       kernel pointer to the first proc structure?  Is there a

       proc structure count?

    *  How does one obtain copies of the proc structures?  Via

       /dev/kmem?  Via a vendor API?

    *  If this is a Mach derivative, is it necessary to obtain the

       task and thread structures?  How?

    *  How does one obtain the user area (or the utask area in Mach

       systems) that corresponds to a process?

    *  Where are the file structures located for open file

       descriptors and how are they located?  Are all file

       structures in the user area?  Is the file structure space

       extensible?

    *  Where do the private data pointers in file structures lead?

       To gnodes?  To inodes?  To sockets?  To vnodes?  Hint: look

       in <sys/file.h> for DTYPE_* instances and further pointers.

    *  How are the nodes organized?  To what other nodes do they

       lead and how?  Where are the common bits of information in

       nodes -- device, node number, size -- stored?  Hint: look

       in the header files for nodes for macros that may be used

       to obtain the address of one node from another -- e.g., the

       VTOI() macro that leads from a vnode to an inode.

    *  Are text reference nodes identified and how?  Is it

       necessary to examine the virtual memory map of a process or

       a task to locate text references?  Some kernels have text

       node pointers in the proc structures; some, in the user

       area; Mach kernels may have text information in the task

       structure, reached in various ways from the proc, user area,

       or user task structure.

    *  How is the device table -- e.g., /dev or /devices --

       organized?  How is it read?  Using direct or dirent structures?

       How are major/minor device numbers represented?  How are

       device numbers assembled and disassembled?

       Are there clone devices?  How are they identified?

    *  How is mount information obtained?  Getmntinfo()?  Getmntent()?

       Some special kernel call?

    *  How are sockets identified and organized?  BSD-style?  As

       streams?  Are there streams?

    *  Are there special nodes -- CD-ROM nodes, FIFO nodes, etc.?

    *  How is the kernel's name cache organized?  Can lsof access

       it to get partial name components?

Dlsof.h and #include's

----------------------

Once you have identified the kernel's data organization and know

what structures it provides, you must add #include's to dlsof.h to

access their definitions.  Sometimes it is difficult to locate the

header files -- you may need to introduce -I specifications in the

Makefile via the DINC shell variable in the Configure script.

Sometimes it is necessary to define special symbols -- e.g., KERNEL,

_KERNEL, _KMEMUSER -- to induce system header files to yield kernel

structure definitions.  Sometimes making those symbol definitions

cause other header file and definition conflicts.  There's no good

general rule on how to proceed when conflicts occur.

Rarely it may be necessary to extract structure definitions from

system header files and move them to dlsof.h, create special versions

of system header files, or obtain special copies of system header

files from "friendly" (e.g., vendor) sources.  The dlsof.h header

file in lsof4/dialects/sun shows examples of the first case; the

second, no examples; the third, the irix5hdr subdirectory in

lsof4/dialects/irix (a mixture of the first and third).

Building up the necessary #includes in dlsof.h is an iterative

process that requires attention as you build the dialect-specific

functions that references kernel structures.  Be prepared to revisit

dlsof.h frequently.

Definitions That Affect Compilation

-----------------------------------

The source files at the top level and in the lib/ subdirectory

contain optional functions that may be activated with definitions

in a dialect's machine.h header file.  Some are functions for

reading node structures that may not apply to all dialects -- e.g.

CD-ROM nodes (cdrnode), or `G' nodes (gnode) -- and others are

common functions that may occasionally be replaced by dialect-specific

ones.  Once you understand your kernel's data organization, you'll

be able to decide the optional common node functions to activate.

Definitions in machine.h and dlsof.h also enable or disable other

optional common features.  The following is an attempt to list all

the definitions that affect lsof code, but CAUTION, it is only

attempt and may be incomplete.  Always check lsof4 source code in

lib/ and dialects/, and dialect machine.h header files for other

possibilities

    AFS_VICE		See 00XCONFIG.

    AIX_KERNBITS	specifies the kernel bit size, 32 or 64, of the Power

			architecture AIX 5.x kernel for which lsof was built.

    CAN_USE_CLNT_CREATE	is defined for dialects where the more modern

			RPC function clnt_create() can be used in

			place of the deprecated clnttcp_create().

    CLONEMAJ            defines the name of the variable that

			contains the clone major device number.

			(Also see HAS_STD_CLONE and HAVECLONEMAJ.)

    DEVDEV_PATH		defines the path to the directory where device

			nodes are stored, usually /dev.  Solaris 10

			uses /devices.

    DIALECT_WARNING	may be defined by a dialect to provide a

			warning message that will be displayed with

			help (-h) and version (-v) output.

    FSV_DEFAULT		defines the default file structure values to

			list.  It may be composed of or'd FSV_*

			(See lsof.h) values.  The default is none (0).

    GET_MAJ_DEV         is a macro to get major portion from device

			number instead of via the standard major()

			macro.

    GET_MIN_DEV		is a macro to get minor portion from device

			number instead of via the standard minor()

			macro.

    GET_MAX_FD		the name of the function that returns an

			int for the maximum open file descriptor

			plus one.  If not defined, defaults to

			getdtablesize.

    HAS9660FS           enables CD9660 file system support in a

			BSD dialect.

    HAS_ADVLOCK_ARGS    is defined for NetBSD and OpenBSD dialects

			whose <sys/lockf.h> references vop_advlock_args.

    HAS_AFS		enables AFS support code for the dialect.

    HAS_AIO_REQ_STRUCT	is defined for Solaris 10 and above systems that

			have the aio_req structure definition.

    HAS_ATOMIC_T	indicates the Linux version has an

			<asm/atomic.h> header file and it contains

			"typedef struct .* atomic_t;"

    HASAOPT		indicates the dialect supports the AFS -A

			option when HAS_AFS is also defined.

    HAS_ASM_TERMIOBITS  indicates for Linux Alpha that the

			<asm/termiobits.h> header file exists.

    HASAX25CBPTR	indicates that the Linux sock struct has an

			ax25_db pointer.

    HASBLKDEV		indicates the dialect has block device support.

    HASBUFQ_H		indicates the *NSD dialect has the <sys/bufq.h>

			header file.

    HASCACHEFS		enables cache file system support for the

			dialect.

    HAS_CDFS		enables CDFS file system support for the

			dialect.

    HASCDRNODE		enables/disables readcdrnode() in node.c.

    HAS_CLOSEFROM	is defined when the FreeBSD C library contains the

			closefrom() function.

    HAS_CONN_NEW        indicates the Solaris version has the new form

			of the conn_s structure, introduced in b134 of

			Solaris 11.  This will always accompany the

			HAS_IPCLASSIFIER_H definition.

    HAS_CONST		indicates that the compiler supports the

			const keyword.

    HASCPUMASK_T	indicates the FreeBSD 5.2 or higher dialect

			has cpumask_t typedef's.

    HAS_CRED_IMPL_H	indicates the Solaris 10 dialect has the

			<sys/cred_impl.h> header file available.

    HASCWDINFO          indicates the cwdinfo structure is defined

			in the NetBSD <sys/filedesc.h>.

    HASDCACHE           enables device file cache file support.

			The device cache file contains information

			about the names, device numbers and inode

			numbers of entries in the /dev (or /device)

			node subtree that lsof saves from call to

			call.  See the 00DCACHE file of the lsof

			distribution for more information on this

			feature.

    HASDENTRY		indicates the Linux version has a dentry

			struct defined in <linux/dcache.h>.

    HASDEVKNC           indicates the Linux version has a kernel

			name cached keyed on device number.

    HAS_DINODE_U	indicates the OpenBSD version has a dinode_u

			union in its inode structure.

    HASDNLCPTR          is defined when the name cache entry of

			<sys/dnlc.h> has a name character pointer

			rather than a name character array.

    HAS_DUP2		is defined when the FreeBSD C library contains the

			dup2() function.

    HASEFFNLINK		indicates the *BSD system has the i_effnlink

			member in the inode structure.

    HASENVDC            enables the use of an environment-defined

			device cache file path and defines the name

			of the environment variable from which lsof

			may take it.  (See the 00DCACHE file of

			the lsof distribution for information on

			when HASENVDC is used or ignored.)

    HASEOPT		indicates the dialect supports the -e option to

			eliminate kernel blocks on a named file system.

    HASEPTOPTS		indicates the dialect supports the +|-E end point

			options.

    HASEXT2FS           is defined for BSD dialects for which ext2fs

			file system support can be provided.  A value

			of 1 indicates that the i_e2din member does not

			exist; 2, it exists.

    HASF_VNODE		indicates the dialect's file structure has an

			f_vnode member in it.

    HAS_FDESCENTTBL	indicates the FreeBSD system has the fdescenttbl

			structure.

    HAS_FILEDESCENT	indicates the FreeBSD system has the filedescent

			definition in the <sys/filedesc.h> header file.

    HASFDESCFS		enables file descriptor file system support

			for the dialect.   A value of 1 indicates

			<miscfs/fdesc.h> has a Fctty definition; 2,

			it does not.

    HASFDLINK		indicates the file descriptor file system

			node has the fd_link member.

    HASFIFONODE		enables/disables readfifonode() in node.c.

    HAS_FL_FD		indicates the Linux version has an fl_fd

			element in the lock structure of <linux/fs.h>.

    HAS_FL_FILE		indicates the Linux version has an fl_file

			element in the lock structure of <linux/fs.h>.

    HAS_FL_WHENCE	indicates the Linux version has an fl_whence

			element in the lock structure of <linux/fs.h>.

    HAS_F_OPEN		indicates the UnixWare 7.x dialect has the

			f_open member in its file struct.

    HASFSINO            enables the inclusion of the fs_ino element

			in the lfile structure definition in lsof.h.

			This contains the file system's inode number

			and may be needed when searching the kernel

			name cache.  See dialects/osr/dproc.c for

			an example.

    HASFSTRUCT		indicates the dialect has a file structure

			the listing of whose element values can be

			enabled with +f[cfn].  FSV_DEFAULT defines

			the default listing values.

    HASFSTYPE           enables/disables the use of the file system's

			stat(2) st_fstype member.

			If the HASFSTYPE value is 1, st_fstype is

			treated as a character array; 2, it is

			treated as an integer.

			See also the RMNT_EXPDEV and RMNT_FSTYPE

			documentation in lib/rmnt.c

    HASFUSEFS		is defined when the FreeBSD system has FUSE file system

			support.

    HASGETBOOTFILE	indicates the NetBSD or OpenBSD dialect has

			a getbootfile() function.

    HASGNODE		enables/disables readgnode() in node.c.

    HASHASHPID		is defined when the Linux version (probably

			above 2.1.35) has a pidhash_next member in

			its task structure.

    HASHSNODE		enables/disables readhsnode() in node.c.

    HASI_E2FS_PTR	indicates the BSD dialect has a pointer in

			its inode to the EXTFS dinode.

    HASI_FFS            indicates the BSD dialect has i_ffs_size

			in <ufs/ufs/inode.h>.

    HASI_FFS1		indicates the BSD dialect supports the fast

			UFS1 and UFS2 file systems.

    HAS_INKERNEL        indicates the SCO OSR 6.0.0 or higher, or

			UnixWare 7.1.4 or higher system uses the

			INKERNEL symbol in <netinet/in_pcb.h> or

			<netinet/tcp_var.h>.

    HASINODE		enables/disables readinode() in node.c.