Re: [B.A.T.M.A.N.] [RFC v2 0/5] batman-adv netlink query API

Matthias Schiffer
2016-04-20T07:32:19Z

[-- Attachment #1.1: Type: text/plain, Size: 3302 bytes --]

On 04/18/2016 04:50 PM, Simon Wunderlich wrote:
> On Thursday 17 March 2016 17:45:30 Matthias Schiffer wrote:
>> Hi,
>> this is the second take of my netlink API patches. As mentioned before, the
>> netlink API is superior to the current debugfs API in many aspects:
>>
>> * debugfs is broken (see PATCH 1 for details)
>> * Netlink is namespace-aware, and can be used in unprivileged containers
>> without problems
>> * Netlink packets are more machine-readable than text files, and can be
>> easily extended without potentially breaking userspace
>> * On older kernels, seq_file can't fall back to vmalloc if kmalloc fails,
>> which often leads to OOM when reading "originators" in large meshes, as
>> the whole file must fit into a single buffer
>>
>> Of course, are also a few downsides; when the data is too big to fit into
>> a single netlink packet, the provided data may be inconsistent (entries may
>> be missing or duplicated.) This will happen in large meshes only, and be
>> improbable in any case.
>>
>> The patches have been developed on top of the netns patchset, but should
>> be applicable independently (maybe with minor changes.)
>>
>> All netlink queries returning lists of any kind can only be used with
>> NLM_F_DUMP queries, so that arbitrarity large responses are possible (split
>> across multiple packets if necessary.)
>>
>> At the moment, the following debugfs files have corresponding netlink APIs:
>>
>> * routing_algos
>> * neighbors
>> * originators
>> * transtable_global
>> * transtable_local
>> * (hardinterfaces for a softif can be queried)
>>
>> The following files are still missing:
>>
>> * gateways
>> * bla_claim_table
>> * bla_backbone_table
>> * dat_cache
>> * nc_nodes
>>
>> Obviously, documentation is also a TODO. Comments about the API design are
>> very welcome...
>>
>> Regards,
>> Matthias
>
> Hi Matthias,
>
> thanks for reposting this and sorry for the long silence. Since we have the
> namespace work from Andrew now which would require netlink support, I think
> its a good time to integrate this. :)
>
> I'll try to look into your patchset this week into more detail and give
> feedback. In the meantime, just a few question:
>
> * Would you like to add netlink support for the missing files as well?
> (gateways, bla, dat, nc)
> * Would you also like to do the batctl support? I guess we can have batctl
> behave "compatible" by trying netlink first and fall back to debugfs for the
> next few years
> * Also open is the icmp socket stuff, which we could postpone and implement
> later.
>
> Just wanted to check with your availability first, but we would like to
> support the netlink adoption. :)
>
> Thanks!
> Simon
>

As Andrew has already started to integrate and extend my patchset, I'll
happily leave further development to him - I'm quite busy with other
projects at the moment, so it would probably take a lot longer if I were to
work on this myself.

As I've mentioned before, regarding the batctl support, I'd love to see a
little library ("libbatadv"?) on top of libnl that could be used by batctl,
alfred and other monitoring tools (like the ones we are using in the Gluon
Freifunk firmwares).

Regards,
Matthias

[-- Attachment #2: OpenPGP digital signature --]