Date: Fri, 10 Jan 2014 19:24:48 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Gleb Smirnoff <glebius@FreeBSD.org>, wollman@freebsd.org Cc: current@freebsd.org, net@freebsd.org Subject: Re: unused in_cksum_update() ? Message-ID: <20140110182448.GA62317@onelab2.iet.unipi.it> In-Reply-To: <20140110103140.GD73147@FreeBSD.org> References: <20140109192114.GA49934@onelab2.iet.unipi.it> <20140110103140.GD73147@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 10, 2014 at 02:31:40PM +0400, Gleb Smirnoff wrote:
> On Thu, Jan 09, 2014 at 08:21:14PM +0100, Luigi Rizzo wrote:
> L> a lot of arch-specific headers (sys/${ARCH}/include/in_cksum.h)
> L> have a lengthy definition for
> L>
> L> in_cksum_update(struct ip *ip)
> L>
> L> which seems completely unused in our source tree.
> L> Time to remove it perhaps ?
> L>
> L> grep cannot find any use at least since stable/8
>
> I'd prefer not to hurry with its removal. Might be that pf will use it.
> Since it lives in a header file, it doesn't add a single bit to kernel
> size.
we should care more about obfuscation and correcteness, and this is
a killer in both respects.
Depending on $arch the function is not even available or wrong:
In particular, the basic code follows the description in
http://tools.ietf.org/html/rfc1141A with ntohs/htons to deal
with endianness (note that the '256' should not be converted):
tmp = ntohs(sum)+256;
tmp = tmp + (tmp >> 16);
sum = htons(tmp); // also truncates high bits
It is correctly implemented (but in a totally generic way, so no
point to have it in the arch-specific files) for amd64, i386,
ia64, mips, powerpc; it is not implemented for arm, and it is wrong
for sparc64 (where the 256 is incorrectly replaced by a 1).
In terms of usage: the svn repo suggests that it was added in r15884
in 1996 (stable/2.2 is the first branch where it appears):
http://svnweb.freebsd.org/base/head/sys/i386/include/in_cksum.h?r1=15884&r2=15883&pathrev=15884
as far as i can tell never used anywhere, and copied from place to
place when we started to support different architectures.
Shall we wait until it becomes 18 ? :)
I am adding Garret to the list as he may have more details.
cheers
luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140110182448.GA62317>