[netfilter-cvslog] r4017 - in trunk/patch-o-matic-ng-2: . patchlets
laforge at netfilter.org
laforge at netfilter.org
Mon Jun 27 11:01:49 CEST 2005
Author: laforge at netfilter.org
Date: 2005-06-27 11:01:49 +0200 (Mon, 27 Jun 2005)
New Revision: 4017
Added:
trunk/patch-o-matic-ng-2/README.newpatches
Removed:
trunk/patch-o-matic-ng-2/patchlets/README.newpatches
Log:
move back toplevel
Copied: trunk/patch-o-matic-ng-2/README.newpatches (from rev 4016, trunk/patch-o-matic-ng-2/patchlets/README.newpatches)
Deleted: trunk/patch-o-matic-ng-2/patchlets/README.newpatches
===================================================================
--- trunk/patch-o-matic-ng-2/patchlets/README.newpatches 2005-06-27 09:01:37 UTC (rev 4016)
+++ trunk/patch-o-matic-ng-2/patchlets/README.newpatches 2005-06-27 09:01:49 UTC (rev 4017)
@@ -1,177 +0,0 @@
-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.
-
-8) 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
More information about the netfilter-cvslog
mailing list