[B.A.T.M.A.N.] [RFC v4] throughput meter on steroids^W netlink

[Sven Eckelmann <sven.eckelmann@open-mesh.com>]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

Hi,

I was asked by the batman-adv maintainers to port the tp_meter to netlink. And
I shouldn't do it with the patches from Andrew/Matthias applied but with only
a small part of patch 4. 

I know, this isn't the nicest move but it allowed me to restructure the first
commit a little bit. I've extracted the part which introduced the netlink
family + a restructured batman_adv.h. I've also added the part which
introduces the generic mesh information as extra patch (+kerneldoc). This
added some attributes which I need in tp_meter. But I can also remove the
patch and only merge the necessary parts.


@Andrew, I hope you don't take it the wrong way. I really like your work and
even borrowed parts of the code for the tp_meter interface. So you are now
allowed to criticize the hell out of the changes and request some free beer
from Antonio, Marek and Simon :). But I hope that you like the adjustments to
the initial parts (at least a little bit). You would have to rebase your
changes (which I still want to get integrated) on top when these things here
are merged. I would also be willing to do the rebase myself and send you the
result (so you can add the kerneldoc and maybe make further adjustments).

The only "big" conflicts I see are related to the order of attributes. But
this was a long day for me and I may have forgotten something.

@the_rest: Do you find the bugs introduced by moving it to netlink?

The one which I know about is the inability to receive signals while the
kernel is doing the wait_event (So the BATADV_CMD_TP_METER_CANCEL doesn't work 
at all). I am waiting for recommendations. The one which
comes to my mind is not to wait for the thing to finish but to just return
immediately. The client would then have to some kind of event listener enabled
which waits until the thing finished. This approach would also require some
kind of session info exchange. Does anyone else have a good idea?

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]