Hi,
On Sun, Aug 30, 2009 at 09:37:52AM +0200, Andrew Lunn wrote:
Cheers, Linus
PPS: I had to introduce a src-field in the vis-packet-struct, therefore the compatibility version had to be increased as well.
I'm thinking about linux-mainline here.
Does it make sense to have a version number per message type? Some things we can do backward compatibility easily, some things not.
I guess it should not be too hard to do backward compatibility here. If you receive a version 7 do the old way of getting the source address. If its a version 8 packet, use the new way?
Generally possible, but as we store the vis information locally in whole packets we have to distinguish everywhere between the versions (packet handling, proc access, etc). This will not make the code look pretty.
Allowing this sort of backward compatibility also makes deployment easier. You currently have a real danger of loosing contact to some of your nodes during software updates. If you do it in the wrong order, you could end up with a disconnected island.
Each software updates on meshed nodes is difficult. Even if you just change the channel, the ESSID/BSSID or other wifi parameters you can end up with islands. Most setup i have seen tried to use software firmwares as homogenous as possible, even if they are a little bit older. Software Updates in mesh networks always require more sophisticated strategies.
Also, once in mainline, the vis file becomes part of the well defined API. It should not just change in ways which are not backward compatible. I'm guessing this change breaks all my tools for parsing vis, and it probably breaks other peoples tools. Ideally, we strip out all graphviz and JSON formatting from the kernel and put it into userspace, eg batctl. Tools should then use batcl. It then becomes safer to change the proc vis format. The output of batctl stays the same, unless you add a command line flag to enable the new feature.
Mhm, even if we had transported the data from kernel to userspace, we would have ended up in a change to this interface as the data format changed (additional source field).
However i've added a compile flag in the reviewed version of linus patch which should give you the possibility to get the "old" vis output.
Generally i think that the patch was really neccesary as the original vis did not consider nodes with multiple interfaces. Disconnected graphs were the result of this, which makes the vis output pretty useless if you employ nodes with multiple interfaces. I think the approach by using clusters is quite good too, even if we (the toolwriters, me included) need to change their parsers now.
This move to mainline requires some adaptations to the development ways. We need to discuss this and need to get the basics sorted out before we do go into mainline. However, it looks like we could be in mainline very quickly if we wanted.
I agree, we should sort this out early. My personal opinion is that the algorithm will be optimized further, and it will make the code unmaintainable to add exceptions for all older versions (especially the various intermediate versions).
As it was pointed out earlier by Marek and Elektra, using multiple versions in one network will most probably lead to "side effects". IMHO it's better to let users know that it won't work properly backward than risking these side effects.
Usually we have stable versions (e.g. batman-adv 0.1) with a specific format, and an ongoing development in the svn trunk. Maybe we should do the same for future kernel development - maintaining one packet and algorithm version in the kernel, and further develop the algorithm on our own (e.g. in a git tree or with sets of patches)? In this case, we should post the current batman-adv to the list when 0.2 is stabilized and finished. Mainline algorithm should only be changed when we reach a new stable version.
best regards, Simon