Hey,

On Wed, Aug 03, 2011 at 06:50:18PM +0200, Andrew Lunn wrote:
> On Wed, Aug 03, 2011 at 04:39:53PM +0200, Marek Lindner wrote:
> > 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.
> 
mhm, I'm not sure if we need to let two different meshes talking (right now),
but a nice compromise might be to enable selecting the algorithm at module
load time as parameter - I would find it inconvenient to re-compile the module 
all the time. :)

This is hopefully not too hard, we could go with a struct of function pointers
as many other subsystems do. This could also be enhanced later to enable 
"real" runtime selection, but there might be some challenges there, e.g. 
changing the sysfs (for algorithm-dependent parameters) and other dependencies.

What do you think?

best regards,
	Simon