BUG REPORTS
Please read this file before sending in a bug report or patch.

Where to send
=============
Send comments, bug reports, patches, etc. to cblake@bbn.com.
{alternate mail addresses in preferential order:
	chuckb@alice.wonderland.caltech.edu
	cblake@alumni.caltech.edu	(forthcoming)
}
Michael K. Johnson has suggested starting a small procps mailing list.

What to send
============
It is much more useful to me if a program really crases to recompile it with
make "CC=gcc -ggdb -O", run it with "gdb prog" and "run" and send me a stack
trace ('bt' command).  That said, any bug report is still better than none.

It might be nice to get rid of miscellaneous compiler warnings, but don't bend
over backwards to do it.

Kernel Dependent Patches
========================
If you send me patches which are specific to *compiling* on a particular version
of Linux include a "#if LINUX_VERSION_CODE > 1*0x10000+3*0x100+54" markup of the
patch so that the package may be compiled with older kernels as well as the
"latest and greatest".  LINUX_VERSION_CODE is #define'd in <linux/version.h>.

If you send me patches which are specific to *running* with a particular kernel
version of /proc, please condition them with the runtime determined variable
`linux_version_code' from libproc/kvers.c.  It is the same number as the macro
LINUX_VERSION_CODE for which the kernel /proc fs code was compiled.

A macro is provide in libproc/version.h to construct the code from its
components, e.g. if (linux_version_code < LINUX_VERSION(1,1,30)) /* tty field is
only a minor */ .  A startup call to set_linux_version may also be necessary.

Of course, if a bug is due to a change in kernel file formats, it would be best
to first try to generalize the parsing, since the code is then more resilient
against future change.

Also context diffs are my preference but anything is better than nothing.

Code Structure
==============
My ultimate goal for this package is to be compilable with any kernel headers
and to be able to run under any kernel's /proc.  (Don't bother telling me that
I'm not especially close to my ultimate goal... who is? :-) 

Anyhow, another goal is to encapsulate *all* parsing dependent on /proc file
formats into the libproc library.  If the API is general enough it can hopefully
stabilize and then /proc changes might only require updating libproc.so.  Beyond
that having the set of utilities be simple command lines parsers and output
formatters and encapsulating all kernel divergence in libproc is the way to go.

Hence if you are submitting a new program or are fixing an old one, keep in mind
that adding files to libproc which encapsulate such things is more desirable
than patching the actual driver program.  (well, except to move it toward the
API of the library).

Micellany
=========
Although I have been rather remiss in keeping procps releases up to the minute
(well, OK, year... ;-), I really do read all the mail and patches that I receive
(usually within a week of getting them).  Sometimes I may let some who deserve
responses slip between the cracks.  You may need to bug me more to get an
immediate response.

I have tested this particular release mostly on 1.3.5[24], libc 5.2.16, gcc
2.7.2.  It needs to be tested more with 1.2.X or early 1.3.X kernels as well as
the latest greatest.  A lot has changed and some bugs no doubt remain.

