Hi,
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/
http://git.open-mesh.net/?p=batman-adv;a=shortlog;h=refs/heads/master
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://downloads.open-mesh.net/svn/batman/trunk/batctl/
*
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
batman-adv.
This branch can be used together with
http://downloads.open-mesh.net/svn/batman/branches/batctl-0.2.x/
* 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
integration.
*
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
buddy.
If you want to try that branch or any snapshot of 2.6.35 then please try
revision r1664 of
http://downloads.open-mesh.net/svn/batman/branches/batctl-0.2.x/
*
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
added
* Makefile is rewritten to look like a stripped down version of
Makefile.kbuild
* 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
GregKH.
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
apply):
* 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
http://downloads.open-mesh.net/svn/batman/trunk/batctl/
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,
Sven