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

[Marek Lindner <lindner_marek@yahoo.de>]

On Wednesday, August 03, 2011 18:50:18 Andrew Lunn wrote:
> > 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.

Agreed.


> 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...

There is no difference between compile time and run time option - both won't 
destroy the other.


> 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.

True. That is an interesting point you are making here.


> > 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?

I'll post a follow-up once it is available.

Regards,
Marek