From: Antonio Quartulli <ordex@autistici.org>
To: "David S. Miller" <davem@davemloft.net>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
James Morris <jmorris@namei.org>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
Patrick McHardy <kaber@trash.net>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: arp.c: external usage
Date: Thu, 24 May 2012 18:07:16 +0200 [thread overview]
Message-ID: <20120524160715.GC6454@ritirata.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]
Hello,
I'm writing here because we, as batman-adv developers, wanted to add a new
feature called D.A.T. (Distributed ARP Table) to the batman-adv module, but we
encountered some issues.
Going into the details, DAT is a DHT (Distributed Hash Table) based ARP cache and
for its purposes it requires a local storage for classic ARP entries. In order
to avoid code duplication, we decided to "consistently" use the local ARP table
provided by the kernel.
These are the operations we wanted to perform on the kernel ARP table:
- Add a new entry
- Check if an entry is present
- Change the default entry timeouts
The code we provided used the following functions provided by the ARP/neighbour
layer API:
- neigh_lookup()
- neigh_release()
- arp_create()
Other than that the code was (necessarily) using "arp_tbl" and was modifying the
timeouts by directly accessing members of "(struct in_device)->arp_parms".
The patches adding the feature has been rejected by David Miller because he
stated that the ARP/neighbour code is going to be heavily modified and for this
reason he wanted to avoid to add other code depending on those components.
You find the emails where David rejected our code here:
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-April/006921.html
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-May/006925.html
The last email from David stated that we must not use ARP/neighbour layer
internals, but all the functions we are using are correctly exported by the
ARP/neigh layer and so are part of the API that we are using.
At this point we are stuck and we don't know how to proceed.
From David's last
email I personally got the impression that we should not use the ARP/neigh layer
at all and so we should implement our own ARP backend (which means duplicating a
lot of code). However this does not sound like a good solution.
If changes for the ARP/neigh layer are already planned, is it possible to know
whether we will be able to perform the aforementioned operations by means of the
new API? Or, do you have any suggestion on how to perform the needed operations
without directly touching the ARP/neigh layer?
Thank you in advance,
Best Regards
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
reply other threads:[~2012-05-24 16:34 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20120524160715.GC6454@ritirata.org \
--to=ordex@autistici.org \
--cc=davem@davemloft.net \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.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
Powered by JetHome