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