netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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).