Hi Folks
Here is a quick summary of the state of batman in mainline.
First a quick summary of how code gets into mainline in general. When Linus released a kernel version, eg 2.6.33, he opens the merge window for the next kernel version. This merge window is normally two weeks long. During these two weeks, all new development work which is intended for 2.6.34 is merged into his tree. At the end of the two weeks the first rc kernel is released, in this case 2.6.34-rc1. At this point no more development work can be merged, just bug fixes. Generally there is a new -rc kernel every week, for about 8 or 9 weeks. So after about three months, the kernel is released, and it all starts again.
This two week merge window is a busy period with all sorts of patches come together. In the past this did not always go too well, patches collided and conflicted. To try to find out about such problems early, before the merge window, the linux-next tree was created. linux-next is roughly all the patches which will be merged in the next merge window. It contains ongoing development work from all over the place. If patches are going to clash, they will likely clash in linux-next and then developers know about such problems early.
O.K. so what is the status of batman-adv?
Our first patch landed by GregKH just before the merge window for 2.6.33 opened. This patch made it into 2.6.33-rc1. So at around the end of march when 2.6.33 is released, we will be in mainline.
All patches submitted after this first big one was after the merge window closed. So they are currently queued up by GregKH. They appear in linux-next and should be accepted during the 2.6.34 merge window.
So we have a few issues to address in the next couple of weeks.
1) We should make it clear on www.open-mesh.org which version of batctl should be used with 2.6.33. The trunk version will not work correctly, an older version is needed. Probably we want to make a tarball release and put it somewhere prominent on the website.
2) We still have the chance to get bug fixes into 2.6.33. Is there anything in 2.6.33-rc5 which can cause oopses, deadlocks, etc?
3) It would be nice if the community actually downloaded 2.6.33-rc5 and tested it. Please report any problems you find.
4) We should review what is currently in subversion but not yet pushed to GregKH ready for 2.6.34. eg gateway support, vis server startup fix, bonding, etc. In another email i will produce a list of patches we should consider.
All this work is currently happening in staging. Once 2.6.33 is released we will get a bit more exposure and hopefully trigger some discussion. 2.6.34-rc1 will be a big step forward and i think at that point we should approach the linux networking guys and ask for a review. That would be one of the first steps of getting out of staging and somewhere under the net directory.
Andrew
Andrew Lunn wrote:
- We should review what is currently in subversion but not yet pushed to GregKH ready for 2.6.34. eg gateway support, vis server startup fix, bonding, etc. In another email i will produce a list of patches we should consider.
Most of the stuff you mentioned are experimental things targeted for 0.3. As it was decided that all development is first done in trunk/master, nothing like that should come in maint until we had enough time to test the experimental patches (aka 0.3 is released). And the stuff in maint should be the things we prepare to send to GregKH (with some minor stuff for kernel integration).
The interesting patches were already cherry-picked to maint by Marek.
As said before, there is still the issue that we still depend on PACKET instead of NET in Kconfig after the skb patch.
Best regards, Sven
Hey,
Our first patch landed by GregKH just before the merge window for 2.6.33 opened. This patch made it into 2.6.33-rc1. So at around the end of march when 2.6.33 is released, we will be in mainline.
All patches submitted after this first big one was after the merge window closed. So they are currently queued up by GregKH. They appear in linux-next and should be accepted during the 2.6.34 merge window.
thanks a lot for posting this overview!
- We should make it clear on www.open-mesh.org which version of batctl should be used with 2.6.33. The trunk version will not work correctly, an older version is needed. Probably we want to make a tarball release and put it somewhere prominent on the website.
Since a while I maintain batctl 0.2.x in its own branch: http://www.open-mesh.org/browser/branches/batctl-0.2.x As the name implies it should be compatible with batman-adv 0.2.x. It does not contain any links and will build right out of this branch. Are there any known incompatibilities between batman-adv in 2.6.33 and this branch ?
- We still have the chance to get bug fixes into 2.6.33. Is there anything in 2.6.33-rc5 which can cause oopses, deadlocks, etc?
As Sven already pointed out I merged all relevant bugfix patches into the maint branch. Unless I overlooked something it should be ready to go.
- We should review what is currently in subversion but not yet pushed to GregKH ready for 2.6.34. eg gateway support, vis server startup fix, bonding, etc. In another email i will produce a list of patches we should consider.
I think we should stick to our original agreement to not push new features too fast. Gateway stuff, bonding, etc need more time to mature. The vis patch is waiting in the maint branch - ready for inclusion. :)
All this work is currently happening in staging. Once 2.6.33 is released we will get a bit more exposure and hopefully trigger some discussion. 2.6.34-rc1 will be a big step forward and i think at that point we should approach the linux networking guys and ask for a review. That would be one of the first steps of getting out of staging and somewhere under the net directory.
Ok, let's see what happens then.
Regards, Marek
On Sat, Jan 23, 2010 at 11:27:30AM +0800, Marek Lindner wrote:
Hey,
Our first patch landed by GregKH just before the merge window for 2.6.33 opened. This patch made it into 2.6.33-rc1. So at around the end of march when 2.6.33 is released, we will be in mainline.
All patches submitted after this first big one was after the merge window closed. So they are currently queued up by GregKH. They appear in linux-next and should be accepted during the 2.6.34 merge window.
thanks a lot for posting this overview!
- We should make it clear on www.open-mesh.org which version of batctl should be used with 2.6.33. The trunk version will not work correctly, an older version is needed. Probably we want to make a tarball release and put it somewhere prominent on the website.
Since a while I maintain batctl 0.2.x in its own branch: http://www.open-mesh.org/browser/branches/batctl-0.2.x As the name implies it should be compatible with batman-adv 0.2.x. It does not contain any links and will build right out of this branch. Are there any known incompatibilities between batman-adv in 2.6.33 and this branch ?
Well, 2.6.33 will have the in kernel dot/json formatting. So the vis stuff in batctl 0.2.x is useless. 0.2.x however no longer has the controls to set the vis format the kernel uses. 2.6.33 still has the old logging concept, so the loglevel command with three levels is wrong and the man page talks about dmesg etc...
In other works, users don't want the tip of 0.2.x, they need 0.2.x from about the end of December. We should make a tarball of this and put it somewhere on the website. The tip of 0.2.x works well for linux-next, but nothing older.
- We still have the chance to get bug fixes into 2.6.33. Is there anything in 2.6.33-rc5 which can cause oopses, deadlocks, etc?
As Sven already pointed out I merged all relevant bugfix patches into the maint branch. Unless I overlooked something it should be ready to go.
I think you missed the point about the merge window etc. Stuff in maint will be merged during the next merged window into 2.6.34, around the beginning of April and will be released end of June. I'm talking about 2.6.33 here, which will be released end of March. We can still get bug fixes into 2.6.33 if we want. Are there any bad bugs in the code from the end of December?
- We should review what is currently in subversion but not yet pushed to GregKH ready for 2.6.34. eg gateway support, vis server startup fix, bonding, etc. In another email i will produce a list of patches we should consider.
I think we should stick to our original agreement to not push new features too fast. Gateway stuff, bonding, etc need more time to mature. The vis patch is waiting in the maint branch - ready for inclusion. :)
O.K, i can push vis stuff into 2.6.34. So you are happy for gateway, bonding etc to go into 2.6.35, merge window beginning of July and released sometime around end of September?
Andrew
On Saturday 23 January 2010 19:14:27 Andrew Lunn wrote:
Well, 2.6.33 will have the in kernel dot/json formatting. So the vis stuff in batctl 0.2.x is useless. 0.2.x however no longer has the controls to set the vis format the kernel uses. 2.6.33 still has the old logging concept, so the loglevel command with three levels is wrong and the man page talks about dmesg etc...
That sounds like the 0.2 release, doesn't it ?
I think you missed the point about the merge window etc. Stuff in maint will be merged during the next merged window into 2.6.34, around the beginning of April and will be released end of June. I'm talking about 2.6.33 here, which will be released end of March. We can still get bug fixes into 2.6.33 if we want. Are there any bad bugs in the code from the end of December?
I misread you then. AFAIK there were no critical bugfixes.
So you are happy for gateway, bonding etc to go into 2.6.35, merge window beginning of July and released sometime around end of September?
Yes, I think that might be a workable plan. We can discuss of the indiviadual features once we get closer to the .35 merge window. In case we find major problems we still can hold them back.
Regards, Marek
On Sat, Jan 23, 2010 at 08:24:57PM +0800, Marek Lindner wrote:
On Saturday 23 January 2010 19:14:27 Andrew Lunn wrote:
Well, 2.6.33 will have the in kernel dot/json formatting. So the vis stuff in batctl 0.2.x is useless. 0.2.x however no longer has the controls to set the vis format the kernel uses. 2.6.33 still has the old logging concept, so the loglevel command with three levels is wrong and the man page talks about dmesg etc...
That sounds like the 0.2 release, doesn't it ?
As i said, its a 0.2 from December. It is not the current 0.2. From the current main.c:
http://www.open-mesh.org/browser/branches/batctl-0.2.x/main.c 41 void print_usage(void) { 42 printf("Usage: batctl [options] commands \n"); 43 printf("commands:\n"); 44 printf(" \tinterface|if [none|interface] \tdisplay or modify the interface settings\n"); 45 printf(" \toriginators|o \tdisplay the originator table\n"); 46 printf(" \tinterval|it [orig_interval] \tdisplay or modify the originator interval in ms\n"); 47 printf(" \tloglevel|ll [level] \tdisplay or modify the log level\n"); 48 printf(" \tlog|l \tread the log produced by the kernel module\n");
loglevel and log are not supported by the 2.6.33 kernel. 2.6.33 uses /proc/net/batman-adv/log_level, not /sys/module/batman_adv/parameters/debug which this version of batctl is trying to use.
49 printf(" \ttranslocal|tl \tdisplay the local translation table\n"); 50 printf(" \ttransglobal|tg \tdisplay the global translation table\n"); 51 printf(" \tvis_server|vs [enable|disable] \tdisplay or modify the status of the VIS server\n"); 52 printf(" \tvis_data|vd [dot|JSON] \tdisplay the VIS data in dot or JSON format\n");
vis_server and vis_data are not supported by 2.6.33. 2.6.33 still has the old json and dot formatting in the kernel and /proc/net/batman/vis being written to enable/disable client/server functionality, read from the get the formatted data.
I think svn revision r1463 of batctl is about right for kernel 2.6.33.
Andrew
On Sunday 24 January 2010 01:50:28 Andrew Lunn wrote:
I think svn revision r1463 of batctl is about right for kernel 2.6.33.
My thinking exactly. So, the tarball in question can be downloaded here: http://downloads.open-mesh.net/batman/stable/sources/batctl/
Regards, Marek
b.a.t.m.a.n@lists.open-mesh.org
-
Andrew Lunn -
Marek Lindner -
Sven Eckelmann