[B.A.T.M.A.N.] The state of batman-adv branches in may 2010

Sven Eckelmann sven.eckelmann at gmx.de
Wed May 26 23:40:32 CEST 2010


as we started to have different branches and repositories, everything became a 
little bit more complex to track. I will try to summarize what and where is 
something going on inside the batman-adv universe.

 * http://downloads.open-mesh.org/svn/batman/trunk/batman-adv-kernelland/

   In trunk is always summer - so changes always(?) enter here and will
   get moved to other branches unless they need some more time to get a fine
   flavor - or at least more testing. Even if everything should hit trunk, it 
   is easier to describe changes in a different place.

   This branch can be used together with

 * http://git.open-mesh.net/?p=batman-adv;a=shortlog;h=refs/heads/maint

   This is were commits are gathered to be send later to the linux kernel
   folks. Only tested features or features which are dependencies for the
   in-kernel batman-adv should enter this branch. We have already created the
   release v0.2.1 only from commits inside that branch while we developed new
   stuff in parallel in trunk.

   Since that release we received smaller patches which were merged into the
   linux mainline first or which were send to us directly from people which
   actually wanted to fix problems of the in-kernel batman-adv directly. We
   had for example style changes or patches which will guarantee that
   batman-adv still builds in upcoming kernel releases - things we otherwise
   would have to analyse after that kernel was released. So instead of having
   a user which notices that batman-adv doesn't build anymore, we got the
   fix for the problem which will exist somewhere in the future directly from
   the people which will create that problem. :)

   As one of the bigger changes we started to port batman-adv from /proc to
   sysfs and debugfs. batctl was also changed to work on top of the new
   configuration and debugging infrastructure. Unfortunately this change is a 
   two step process. First we changed everything from /proc to sysfs and later
   moved parts of the files in sysfs to debugfs because they were not single
   value files. But later more about those changes in maint-0.2.2.

   Beside smaller bugfixes, a bigger problem was found when receiving an
   enormous amount of broadcast packets which must be rebroadcasted. It could
   happen that those packets looped inside the mesh. It was tried to fix that
   problem without changing the packet format. Even if that reduced the
   problem, there are more changes coming later which needs changes to the
   packet format.

   Also a smaller new feature has entered maint - the ability to allow
   netfilter/ebtables to filter incoming packets which are directly for

   This branch can be used together with

 * linux-2.6.35

   The merge window has opened over a week ago and all patches (patches we
   send at least a week before it was opened) were accepted. Newer bugfixes
   will probably accepted in some days. Unfortunately some patches like the
   move of some files to debugfs weren't finished right in time and will only
   be merged into linux-2.6.36 because they are more than just simple
   bugfixes. That includes the removing of /dev/batman-adv in favor of
   debugfs, moving of tables from sysfs to debugfs and the netfilter

 * http://git.open-mesh.net/?p=batman-adv;a=shortlog;h=refs/heads/maint-0.2.2

   As we weren't able to merge all patches inside maint in linux-2.6.35 and we
   still want to be able to provide a release which behaves like the version
   in 2.6.35, it was decided that we just use a version before the debugfs
   patches and create a branch which will gather all bugfixes in maint. It
   will be merged and removed after the release of batman-adv-kernelland-0.2.2
   or plans are changed. So better don't start a friendship with this little

   If you want to try that branch or any snapshot of 2.6.35 then please try 
   revision r1664 of

 * http://git.open-mesh.net/?p=batman-adv;a=shortlog;h=refs/heads/linux

   The dirty place were all the linux integration happens. It is ugly,
   misunderstood and uninteresting for most people.

   The last synchronization point was GregKH-20100522. It is a merge of
   v2.6.34 and v0.2.1-38-gbcde864 + a documentation of all files we create in
   sysfs. So this synchronization point (a git tag) just says that we check at
   least v2.6.34 for new patches not yet integrated in maint/trunk of
   batman-adv and that we send our changes until that point to GregKH.

   In reality the patches are modified a little bit.
    * Files are moved from / to /drivers/staging/batman-adv
    * compat.h, bat_printk.c, Makefile.kbuild are removed
    * all references (#include) to compat.h are removed
    * TODO, Kconfig, sysfs-class-net-batman-adv and sysfs-class-net-mesh are
    * Makefile is rewritten to look like a stripped down version of
    * All passages how to compile batman-adv outside of the kernel are removed
      from README
    * Squashed with patches which only fix another patch

   All those changes are done for each patch (or at least ensured that no
   changes will conflict with those points) on top of the last merge point.
   This should ensure that we don't diverge too much from maint with the
   in-kernel batman-adv.

   Each patch is then applied on top of a current linux-next, tested if it
   compiles, checked with sparse and checkpatch.pl --strict. When everything
   looks fine, they get exported again using git-format-patch and send to

   Only because a change is part of a synchronization point, it doesn't mean
   that it will appear with the next linux kernel. As said before, all 
   bugfixes between GregKH-20100510 and GregKH-20100522 will be part of
   2.6.35, but anything bigger will be part of 2.6.36.

 * http://git.open-mesh.net/?p=ecsv/master-rebase.git;a=shortlog;h=rebase

   My personal project. (With a little delay) I will try to get all changes in
   trunk rebased on top of maint. As result we get only the essence of changes
   in trunk which aren't already part of maint. This also means for example
   that patches will look like they were made with sysfs in mind even when
   they are originally created files in /proc. Even when I always ensure that
   the files in master and rebase are 100% equal, the original author may not
   be blamed when a single patch will try to eat your pet (or you could say
   that patches in that branch will not be checked by their original authors
   and I will only guarantee that when you apply all patches you will get the
   same files as in trunk).

   Nevertheless it is a great place to get and test feature patches on top of
   maint without using the complete set of changes in master. Or to understand
   what goes on in trunk compared to maint.

   Of course you cannot use all patches in any order because they have
   dependencies between each other. A the moment we have following patches
   which should be quite easy to use together with any other patch:

    * batman-adv: mark trunk as 0.3.0 alpha
    * batman-adv: Add bonding functionality
    * batman-adv: move queue counters into bat_priv

   We have also patches which changes the packet compat version to 9 (all
   gateway patches must be used in that order, otherwise they would not
    * batman-adv: adding gateway functionality
    * batman-adv: send DHCP requests directly to the chosen gw
    * batman-adv: best gw DHCP filter 802.1Q support
    * batman-adv: record route for ICMP messages

   The last patch increases the compat version 10 and thus requires the
   patches which justify the compat version 9 ("adding gateway functionality",
   "record route for ICMP messages"):
    * batman-adv: 32bit sequence number and TTL for broadcasts

   This branch will jump around and it is not save to track it using a local
   git branch.

   This branch can be used together with

Last but not least, thanks to everyone who has done the real work
 * Andrea Gelmini
 * Andrew Lunn
 * Dan Carpenter
 * Daniel Seither
 * Linus Lüssing
 * Marek Lindner
 * Paul E. McKenney
 * Simon Wunderlich
 * Tejun Heo
and lets see what the next months will bring us.

Best regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.open-mesh.org/pipermail/b.a.t.m.a.n/attachments/20100526/f4dc228a/attachment.pgp>

More information about the B.A.T.M.A.N mailing list