1 This is dhcpd-pools which is made for ISC dhcpd pool range analysis.
5 With this command you can check usage of pool addresses when address space
6 is great. Command is designed so that it will not get slow even there is
7 thousands of IPs in lease file. This kind of huge dhcpd installation can be
8 near by DSL DSLAMs or some other public access connection points.
10 This command will not print nice to know information like DHCPStatus does.
11 Output is limited only to list only usage for ranges, shared network and
12 total address space. Limiting what is printed is the right thing to do when
13 there is thousands of addresses. If your address space is small some other
14 dhcp analyzer might be more suitable for you.
16 == Instructions for developers
20 * "./autogen.sh" generates all files needed to compile and install the
21 code (run it after checkout from git)
23 * "make distclean" removes all unnecessary files, but the code can
24 still be recompiled with "./configure; make"
28 * First get familiar with git. In case you are completely lost watch
29 Greg Kroah-Hartman explaining the very basics.
30 http://archive.fosdem.org/2010/schedule/events/linuxkernelpatch
32 * Get up to date version of the code base.
34 $ git clone git://dhcpd-pools.git.sourceforge.net/gitroot/dhcpd-pools/dhcpd-pools
36 * Don't include generated (autotools) stuff to your patches (hint: use
39 * Add a Signed-off-by line, use "git commit -s"
41 * Patches are delivered via email only. The following commands will do
44 $ git format-patch -C origin/master..yourbranch -o ~/patches
46 When you send only one patch use the following.
48 $ git send-email --to kerolasa@iki.fi 0001*
50 The command above expects you have configured email sending properly.
51 See git.wiki for help.
52 https://git.wiki.kernel.org/index.php/GitTips#Mail
54 * One patch per email, with the changelog in the body of the email.
56 * When you send series of pathes include introductory message.
58 $ git send-email --compose --to kerolasa@iki.fi ~/00*
60 Good introductory message will have at least
64 firstfile.c: short description
65 secondfile.c: another description
70 2 files changed, 3 insertions(+), 3 deletions(-)
73 Above introductory can be generated with git.
75 $ git shortlog master..yourbranch
76 $ git diff --stat master..yourbranch
78 * Subject: [PATCH] subsystem: description. Following ~/.gitconfig will
84 email = your.name@example.com
93 cc = your.name@example.com
96 * If someone else wrote the patch, they should be credited (and blamed)
97 for it. To communicate this, add a line:
99 From: John Doe <jdoe@wherever.com>
101 The sign-off is a simple line at the end of the explanation for the
102 patch, which certifies that you wrote it or otherwise have the right
103 to pass it on as a open-source patch. The rules are pretty simple: if
104 you can certify the below:
106 By making a contribution to this project, I certify that:
108 (a) The contribution was created in whole or in part by me and I
109 have the right to submit it under the open source license
110 indicated in the file; or
112 (b) The contribution is based upon previous work that, to the
113 best of my knowledge, is covered under an appropriate open
114 source license and I have the right under that license to
115 submit that work with modifications, whether created in whole
116 or in part by me, under the same open source license (unless
117 I am permitted to submit under a different license), as
118 indicated in the file; or
120 (c) The contribution was provided directly to me by some other
121 person who certified (a), (b) or (c) and I have not modified
124 (d) I understand and agree that this project and the contribution
125 are public and that a record of the contribution (including
126 all personal information I submit with it, including my
127 sign-off) is maintained indefinitely and may be redistributed
128 consistent with this project or the open source license(s)
131 then you just add a line saying
133 Signed-off-by: Random J Developer <random@developer.example.org>
135 using your real name (sorry, no pseudonyms or anonymous contributions.)
137 * If the the business with git is too difficult just send source code
138 files as is as email attachment to maintainer.
142 * The preferred coding style is based on the linux kernel Documentation/CodingStyle.
143 For more details see:
145 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/CodingStyle
147 * Source code is pretty printed by using two, and only the two, indent
148 command switches -kr -i8