public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Simon Wunderlich <sw@simonwunderlich.de>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] [RFC v2 0/5] batman-adv netlink query API
Date: Mon, 18 Apr 2016 16:50:26 +0200	[thread overview]
Message-ID: <3565172.dz0c0eMaPu@prime> (raw)
In-Reply-To: <cover.1458231707.git.mschiffer@universe-factory.net>

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

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

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

  parent reply	other threads:[~2016-04-18 14:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-17 16:45 [B.A.T.M.A.N.] [RFC v2 0/5] batman-adv netlink query API Matthias Schiffer
2016-03-17 16:45 ` [B.A.T.M.A.N.] [RFC v2 1/5] batman-adv: add generic netlink query API to replace debugfs files Matthias Schiffer
2016-03-17 16:45 ` [B.A.T.M.A.N.] [RFC v2 2/5] batman-adv: netlink: add translation table query Matthias Schiffer
2016-03-17 16:45 ` [B.A.T.M.A.N.] [RFC v2 3/5] batman-adv: netlink: add originator and neighbor table queries Matthias Schiffer
2016-03-17 16:45 ` [B.A.T.M.A.N.] [RFC v2 4/5] batman-adv: add B.A.T.M.A.N. IV bat_{orig, neigh}_dump implementations Matthias Schiffer
2016-03-17 16:45 ` [B.A.T.M.A.N.] [RFC v2 5/5] batman-adv: add B.A.T.M.A.N. V " Matthias Schiffer
2016-03-17 17:04 ` [B.A.T.M.A.N.] [RFC v2 0/5] batman-adv netlink query API Matthias Schiffer
2016-03-18  7:09   ` Sven Eckelmann
2016-03-18 11:53     ` Matthias Schiffer
2016-04-18 10:59       ` Sven Eckelmann
2016-03-18 11:23 ` Sven Eckelmann
2016-03-18 12:00   ` Matthias Schiffer
2016-03-18 12:04     ` Sven Eckelmann
2016-03-19  8:49       ` Antonio Quartulli
2016-03-19  9:19         ` Sven Eckelmann
2016-04-18 11:10           ` Sven Eckelmann
2016-04-18 14:50 ` Simon Wunderlich [this message]
2016-04-20  2:31   ` Andrew Lunn
2016-04-20 11:39     ` Simon Wunderlich
2016-04-20  7:32   ` Matthias Schiffer
2016-04-20  7:39     ` Sven Eckelmann
2016-04-20  7:49       ` Matthias Schiffer
2016-04-20  7:53         ` Sven Eckelmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3565172.dz0c0eMaPu@prime \
    --to=sw@simonwunderlich.de \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox