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