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 . 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.