procps 010114
[procps:crrodriguezs-procps.git] / BUGS
1 BUG REPORTS
2
3 Please read this file before sending in a bug report or patch.
4
5 Also, PLEASE read the documentation first.  90% of the mail I get
6 complaining about procps is due to the sender not having read the
7 documentation!
8
9
10 Where to send
11 =============
12 Send comments, bug reports, patches, etc., to acahalan@cs.uml.edu
13
14
15 What to send
16 ============
17 It is much more useful to me if a program really crases to recompile it
18 with make "CC=gcc -ggdb -O", run it with "gdb prog" and "run" and send
19 me a stack trace ('bt' command).  That said, any bug report is still
20 better than none.
21
22 It might be nice to get rid of miscellaneous compiler warnings, but
23 don't bend over backwards to do it.
24
25
26 Kernel-Dependent Patches
27 ========================
28 If you send me patches which are specific to *running* with a particular
29 kernel version of /proc, please condition them with the runtime determined
30 variable `linux_version_code' from libproc/kvers.c.  It is the same
31 number as the macro LINUX_VERSION_CODE for which the kernel /proc fs
32 code was compiled.
33
34 A macro is provide in libproc/version.h to construct the code from its
35 components, e.g.
36   if (linux_version_code < LINUX_VERSION(1,1,30))
37      /* tty field is only a minor */
38 A startup call to set_linux_version may also be necessary.
39
40 Of course, if a bug is due to a change in kernel file formats, it would
41 be best to first try to generalize the parsing, since the code is then
42 more resilient against future change.
43
44 If you send me patches which are specific to *compiling* on a particular
45 version of Linux include a "#if LINUX_VERSION_CODE > 1*0x10000+3*0x100+54"
46 markup of the patch so that the package may be compiled with older
47 kernels as well as the "latest and greatest".  LINUX_VERSION_CODE is
48 #define'd in <linux/version.h>.
49
50 Note that you should not make patches specific to *compiling* on a
51 particular version of Linux unless there is nothing else you can do.
52
53 Also unified diffs (diff -u) are my preference, context diffs (diff -c )
54 are kind of usable, and standard diffs (diff) are more useless than a
55 generic text description of what you did.  Just use
56         diff -u oldfile newfile
57 or
58         diff -Naur old-procps-dir new-procps-dir
59 to create your diffs and you will make me happy.  Also make sure to
60 include a description of what the diff is for or I'm likely to ignore
61 it because of general lack of time...
62
63
64 Code Structure
65 ==============
66 My ultimate goal for this package is to be compilable with any kernel
67 headers and to be able to run under any kernel's /proc.  (Don't bother
68 telling me that I'm not especially close to my ultimate goal... who
69 is? :-)
70
71 Anyhow, another goal is to encapsulate *all* parsing dependent on /proc
72 file formats into the libproc library.  If the API is general enough
73 it can hopefully stabilize and then /proc changes might only require
74 updating libproc.so.  Beyond that having the set of utilities be simple
75 command lines parsers and output formatters and encapsulating all kernel
76 divergence in libproc is the way to go.
77
78 Hence if you are submitting a new program or are fixing an old one, keep
79 in mind that adding files to libproc which encapsulate such things is
80 more desirable than patching the actual driver program.  (well, except
81 to move it toward the API of the library).