| BUG REPORTS |
| |
| Please read this file before sending in a bug report or patch. |
| |
| Also, PLEASE read the documentation first. 90% of the mail I get |
| complaining about procps is due to the sender not having read the |
| documentation! |
| |
| |
| Where to send |
| ============= |
| Send comments, bug reports, patches, etc., to albert@users.sf.net |
| |
| |
| What to send |
| ============ |
| It is much more useful to me if a program really crashes 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. |
| |
| strace and ltrace output are very helpful: |
| |
| strace -o output-file ps --blah |
| bzip2 output-file |
| |
| 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 *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(2,5,41)) |
| /* blah blah blah */ |
| 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 unified diffs (diff -u) are my preference, context diffs (diff -c ) |
| are kind of usable, and standard diffs (diff) are more useless than a |
| generic text description of what you did. Just use |
| diff -Naurd oldfile newfile |
| or |
| diff -Naurd old-procps-dir new-procps-dir |
| to create your diffs and you will make me happy. Also make sure to |
| include a description of what the diff is for or I'm likely to ignore |
| it because of general lack of time... |
| |
| |
| Code Structure |
| ============== |
| |
| A 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). |