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?
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.
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.
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.
Andrew