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
