On Tue, Jun 21, 2011 at 03:12:31PM +0200, Sven Eckelmann wrote:
Hi,
after the last mail of David S. Miller, it was more than clear that I am not the right person to speak on behalf of the batman-adv community.
Hi Sven
You have done great work with git, getting RCU correct, cleanup, etc. Even if you don't feel capable of speaking on behalf of the batman-adv community in the direction of David S. Miller, i hope you can stay around and contribute to the project.
I have the same opinion about the always changing protocol as he does. I first struggled with it after getting the batman dissector merged in wireshark, but it is confronting everyone since the merge into the linux kernel began. Andrew already told us that we would need to get some kind of stable on the wire format and some kind of backward compatibility, but it doesn't look like we get there soon.
There are some big changes in the pipeline. NDP from Linus, HNA/TT changes from Antonio, Multicast from Linus and Simon, Linus's GSOC work, other things i've forgotten....
Here is a few ideas for discussion.....
Explain to David that these changes are in the pipeline. Explain what benefits they bring. And probably most importantly, try to promise they will all arrive at once. This might mean delaying some features for a while, but it will upset compatibility the least. After that, there will not be any none compatible changes for "a long time". We should discussion here what "a long time" means, eg 4 kernel cycles, 8 kernel cycles, etc.
At the same time as getting these big changes ready to go, it would be good to ensure that we have options to make backward compatible changes during this "long time". I would suggest we document all the available reserved bits we have in the different messages. Ensure they are always set to 0 in the current implementation when creating messages and always ignored when receiving messages. Also, for messages which are forwarded, maybe it makes sense to ensure that a well defined number of the reserved bits get forwarded as they are received and the rest get reset back to 0. Also, received messages of unknown type are silently dropped. Maybe, unknown messages with a particular bit set could be forwarded using the routing table, using an originator address in a well known location in the message.
The point of this is to put infrastructure in place to allow the protocol to be extended without breaking compatibility. It will limit what can be added as new features, cause more headaches while figuring out how to implement something using only this infrastructure, but will keep a lot of people happy they don't need a flag day when upgrading their kernel to an incompatible batman-adv version.
Andrew