- 论坛徽章:
- 0
|
[root@postfix patch-o-matic-ng-20071117]# more README.newpatches
Here is how to add your new `foo' patch to patch-o-matic-ng:
1) Create the directory `foo' to hold the files of your patch.
2) Create a kernel patch by 'diff', which can then be applied
inside the kernel tree by `patch -p1' and call it
`foo/linux.patch'. If your patch works with 2.4 or 2.6 kernel
tree only, then encode the version dependency in the patch name
as `foo/linux-2.4.patch' or `foo/linux-2.6.patch` respectively.
3) Create an info file called `foo/info' with the content:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Title: terse description of the patch
Author: author (name, E-mail address)
Status: Testing|Experimental|Alpha|Beta|Stable
Repository: submitted|pending|base|extra
Requires: repository-entry ==|>|<|>=|<= kernel-version|iptables-version
Depends: [!]patch-name
Recompile: kernel|netfilter|iptables
Successor: patch-name
After an empty line, the description of your patch for
patch-o-matic-ng.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
The `Repository' entry is mandantory, the other ones are optional.
`Requires', `Depends' and `Recompile' entries may occur multiple times.
As we already mentioned, version dependency can be encoded in the
repository entry name. But version dependency can be specified by
the `Requires' entries too, where the repository entry is the name
of the patch file or patch directory tree under the patch directory
'foo', for which the requirement must be fulfilled. For example
the following conditions:
Requires: linux-2.4 >= 2.4.25
Requires: linux-2.4.patch >= 2.4.25
means
- first, the files under the directory linux-2.4 and the patch file
linux-2.4.patch can be applied for kernels from the 2.4 series,
according to the name encoding
- and second, according to the requirement, these patches are specifically
valid for kernels equal or above 2.4.25 from the 2.4 series.
Please note, the same version dependency can be achieved by name encoding
as well: linux-2.4.25.patch can be applied for kernel versions equal above
2.4.25 in the 2.4 kernel tree. However, if linux-2.4.25.patch is valid
for 2.4.25 only, you *must* use the additional requirement line
Requires: linux-2.4.25.patch == 2.4.25
in order to fully specify the version dependency.
When checking the version requirements first name encoding is checked
then the requirements specified in the info file.
Dependency or clash with other patches can be specified by the `Depends'
entries. You specify the name of the patch your patch depends on or clashes
with, at the latter case the patch name preceded by '!'.
With the `Recompile' entries you can (and please do) give hints to the users
what to recompile after applying your patch: the kernel outside the netfilter
part; the netfilter part of the kernel; or the iptables binary. When adding
a new match/target feature patch, you usually have to add
Recompile: netfilter
Recompile: iptables
Dependencies and recompile hints can be listed separated by comma and/or space:
Depends: foo, !bar
Recompile: netfilter, iptables
There is no such possibility for requirements.
When 'bar' patch depends on 'foo' patch and both patches are already applied,
it can occur that patch-o-matic cannot detect that 'foo' is already applied
due to the "clashing" modifications is 'bar'. You can give a hint to pom then
by specifying
Successor: bar
in the info file of 'foo' to resolve the issue, by checking wether 'bar' patch
is applied if 'foo' seems to be not applied. If pom finds that 'bar' applied,
it will assume that 'foo' applied too.
4) If your patch creates a new CONFIG option, modifies Makefile, adds new
entry to specific files (net/ipv4/netfilter/ip_conntrack.h) or adds whole
files to the kernel source tree, then create a patch kernel directory tree
structure to hold these files, say
foo/linux/include/linux/netfilter_ipv4/
foo/linux/include/linux/netfilter_ipv6/
foo/linux/net/ipv4/netfilter
foo/linux/net/ipv6/netfilter
You can use version encoding in the name of the 'linux' directory too, as
described above.
5) If your patch adds whole files to the kernel source, eliminate those
from the patch above and add the whole files (not as patch file!) to
the patch kernel directory tree.
6) If your patch creates a new CONFIG option, eliminate that from the
patch above. Depending on the kernel version:
For a 2.4 kernel create a file called
`foo/linux/net/ipv{4|6}/netfilter/Config.in.ladd'. The format of
this file is as follows:
EXACT LINE TO FOLLOW
<text to paste in>
This allows you to specify the entry in net/ipv4/netfilter/Config.in
that you wish your text to follow. Note that it must be an exact match.
You can have more than one of these files, to make multiple entries
in different places as Config.in.ladd, Config.in.ladd_2, etc.
You also need to make an entry in Documentation/Configure.help;
once again, eliminate this from your patch file and create a file
called `foo/linux/Documentation/Configure.help.ladd' like so:
EXACT CONFIG OPTION TO FOLLOW
<text to paste in>
Your text will be placed after the config option you indicated
(with a blank line before and after). You can have more than one
of these files, to make multiple entries in different places, by
calling successive Configure.help.ladd(_n) files.
For a 2.6 kernel create a file called
`foo/linux/net/ipv{4|6}/netfilter/Kconfig.ladd' with your new
configuration options with the help text included.
7) If you want to add new parts to a Makefile, ip_conntrack.h or other
files with already existing well defined "entry points", eliminate
that from the patch above and create a file `file-to-be-modified.ladd'
in the patch directory tree. The format of the file is as follows:
EXACT LINE TO FOLLOW
<text to paste in>
You can have more than one of these files to make multiple entries
in different places, by calling successive file-to-be-modified.ladd(_n)
files.
 If your original patch file has been completely emptied by removing
the parts above then just remove the empty patch file from the patch
directory.
9) For the usespace part, create the directory tree
foo/iptables/extensions
for the libipt_foo.c whole file. Add a test for your extension called
`foo/iptables/extensions/.foo-test'. This should be a small shell
script which prints the names of the libraries to be built if the
corresponding include file exists in the kernel tree (this test may
be more complex: figure out some way of reliably detecting that the
kernel patch has been applied to $KERNEL_DIR). Typically your test
script could look like this
#!/bin/sh
# True if foo is applied
[ -f $KERNEL_DIR/include/linux/netfilter_ipv4/ipt_foo.h ] && echo foo
10) Add a man page entry, describing the functionality of your extension
as foo/iptables/extensions/libipt_foo.man.
11) If you patch the iptables source besides adding whole files, you
can add that part as `foo/iptables.patch'.
Enjoy!
Netfilter Core Team
难道是这个的原因？？ |
|
免费注册
发表于 2007-11-19 14:47
发表于 2007-11-19 14:58
