Thread (14 messages) 14 messages, 3 authors, 2011-08-18

Re: [B.A.T.M.A.N.] routing code re-organization / the road ahead

From: Andrew Lunn <andrew@lunn.ch>
Date: 2011-08-03 16:50:18

On Wed, Aug 03, 2011 at 04:39:53PM +0200, Marek Lindner wrote:
Hi,
quoted
Looking at the header files, it is not clear to me which contains this
routing algo API. Is it bat_ogm.h?
yes, it is.

quoted
Has there been any discussion if compile time is sufficient? How about
making it a runtime decision? I presume mixing routing algorithms
within a mesh is not going to work. However, being able to configure
the algorithm per mesh should be possible. This gives a greater degree
of interoperability, which might make the Linux Network maintainers
happier?
we discussed various options but at the end decided to move forward with the 
compile time option. Personally, I doubt many people will want the new routing 
algorithm until it has been stabilized (we will provide a 'default' option 
that enables B.A.T.M.A.N. IV).
So it is maybe not needed now, but once the code does start reaching
stability, run time selection becomes more interesting.
Nevertheless, I am not against having the run time option if someone wants to 
do it. Are you going to provide the necessary patches ?
Probably not, at least not now.
 
Where is the interoperability coming from ? The protocols won't be compatible.
Interoperability has many meanings. I've seen it mean the protocol
does not actively destroy the operation of another protocol. I've seen
this in powerline networks. Company X proprietary powerline protocol
is interoperable with HomePlug in that it will not destroy the
HomePlug network if run in parallel with it. It won't talk to it
either...

By making it a runtime option, i don't need to recompile my kernel to
swap from one to the other. I just need "batctl algo V" or "batctl
algo IV". My kernel is interoperable, i just need to configure the
mesh correctly for it to work.

What might also be interesting is
batctl algo IV bat0
batctl algo V bat1
brctl addif br0 bat0
brctl addif br0 bat1

It won't give optimal routes, but it at least gets the two meshs
talking to each other.
However, we are planing on integrating an extensible header format which 
allows to add features that will be backward compatible.
Ah, good. Is there any documentation about this?

    Thanks
	Andrew
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help