From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
To: netdev@vger.kernel.org
Subject: [RFC] net/ipv{4,6} UDP-Lite: code sharing between udp.c and udplite.c
Date: Thu, 22 Jun 2006 08:20:04 +0100 [thread overview]
Message-ID: <200606220820.05056@strip-the-willow> (raw)
I would greatly value comments on a suggestion made earlier by Yoshifuji
regarding sharing code between udp.c and udplite.c which I am pursuing.
I reduced diffs between ipv4/udp{,lite}.c to the minimum possible and
performed a line-by-line comparison between udp.c and udplite.c.
Result: out of 45 functions which re-appear from udp.c in udplite.c,
* 26 can be derived without human thinking at all (sed/perl)
* 10 require trivial interaction (sockopt/header names)
* 8 require genuine modifications (in control flow and algorithm)
* 1 function is missing in udplite.c (no equivalent of udp_check())
Problem: The UDP code (and in particular the replicated functions) operate
on the following globally visible symbols:
EXPORT_SYMBOL(udp_hash); /* would be udplite_hash */
EXPORT_SYMBOL(udp_hash_lock); /* would be udplite_hash_lock */
EXPORT_SYMBOL(udp_port_rover); /* would be udplite_port_rover */
This would lead to clashes if udp.c/udplite.c use the same names.
Suggestion: #include code from udp.c in a much-reduced udplite.c, after
re-defining symbols, so that the top of udplite.c looks like e.g.
#include <linux/udplite.h>
#define udp_hash udplite_hash
#define udp_port_rover udplite_port_rover
#include "udp.c" /* include the source code */
Inputs: The benefits are a much deflated patch, code reuse, increased
clarity (only the diffs are visible). This comes at the cost
of introducing a few #ifdefs in udp.c (otherwise no changes).
However, I am not sure whether such an approach would find
acceptance and therefore I am asking for input. As currently the
porting to ipv6/udplite.c is under way, I would like to take any
suggestions on board which can reduce dependencies and inflated
code.
Many thanks in advance,
--Gerrit
NB: Details of the code analysis can be found on
http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/udplite-comparison.html
and the diff-minimized variant of ipv4/udplite.c is in the latest tarball,
http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/udplite_linux.tar.gz
(any future patches will have the linelengths cut to 80 chars).
reply other threads:[~2006-06-22 7:20 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=200606220820.05056@strip-the-willow \
--to=gerrit@erg.abdn.ac.uk \
--cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).