Hi,

Marek and I have been chatting a little about the buggy vis raw
output yesterday. And there was either the option to sort the
mixed list on the receiving vis server or on the sender already.
For the second option there was also the idea of changing the vis
packet format accordingly to also save some more overhead.
Currently, we're sending a mixed list of (src,dest,quality) with
the struct vis_info_entry. Instead, the idea for a new format was
the following:

vis_packet.entries = number of source interfaces of this originator
followed by tuples
{src,num_neighbours,num_neighbours x {dest,quality}}
for each source interface of a node.

Additionally, the first entry shall be the one of the primary
interface already.

I've made a little prototype patch, see the attachment for this
(it applies on top of Simon's last vis_refcount additions patch).
I haven't done the more difficult part yet, the sorting and
structuring that has to be done in the generate_vis_packet()
instead now.

If you think this kind of format is ok, then I'd like to have some
more opinions of how to deal with the structuring in the
generate_vis_packet(). My idea so far is, to create num_if lists
and malloc and copy the information for every neighbour of an
originator during the locked orig_hash iteration and freeing as
well as packing those list after realeasing the lock. Or, if the
mallocs might take too much time for being used so often during
the lock, to allocate num_ifs buffers with the maximum
vis_packet size (currently 1000B) for each interface batman is
using before entering the spinlock. And I guess, that anyway
num_ifs would have to be made an atomic_t, right?

Cheers, Linus

PS: Could someone explain, why the recv_list_add() is being done
with a sender_orig instead of vis_orig? Because if using vis_orig,
then we could get rid of the sender_orig as well because of having
this information in the ethernet header already.