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
