From owner-freebsd-current@FreeBSD.ORG Tue Apr 26 20:01:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65E1B16A4CE for ; Tue, 26 Apr 2005 20:01:35 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24C7E43D2D for ; Tue, 26 Apr 2005 20:01:35 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.10.18.98] (mail.atheros.com [65.212.155.130]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j3QK1Ums071302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2005 13:01:31 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <426E9E1C.6020609@errno.com> Date: Tue, 26 Apr 2005 13:01:32 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <200504261143.55195.josemi@redesjm.local> <20050426194208.GB7773@ns1.xcllnt.net> In-Reply-To: <20050426194208.GB7773@ns1.xcllnt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-vtss-Metrics: ebb.errno.com 1018; Body=3 Fuz1=3 Fuz2=3 cc: freebsd-current@freebsd.org cc: Jose M Rodriguez Subject: Re: rigth crc32 implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2005 20:01:35 -0000 Marcel Moolenaar wrote: > On Tue, Apr 26, 2005 at 11:43:54AM +0200, Jose M Rodriguez wrote: > >>My first think was use the libkern based one, but I found: >>sys/linkern/crc32.c >> >>- the code may not be endian safe. > > > It operates on bytes, so it's endian-safe. Note that the uint32_t > that's returned is not subject to endianness issues: it's always > in the native byte order. The caller of crc32 needs to byteswap > if it needs to compare this integral with a CRC that's not in > the native byte order. > > >>- the code lacks support for processing chuncks. > > > This should be easy enough to add. We could add an alternative > version that also takes the initial CRC value. The initial CRC > value can be the calculated CRC of a previous chunk. This also > solves the problem that some CRC calculations start with a CRC > of 0U, while others start with a CRC of ~0U. See also: > http://www.repairfaq.org/filipg/LINK/F_crc_v34.html#CRCV_003 > > Roughly speaking (ok, not quite) this is what needs to happen: > > uint32_t > crc32_raw(const void *buf, size_t size, uint32_t crc) > { > const uint8_t *p = buf; > > while (size--) > crc = crc32_tab[(crc ^ *p++) & 0xFF] ^ (crc >> 8); > > return (crc); > } > > uint32_t > crc32(const void *buf, size_t size) > { > uint32_t crc; > > crc = crc32_raw(buf, size, ~0U); > return (crc ^ ~0U); > } > > Here, crc32_raw() allows the caller to specify the initial CRC value > as well as allows the caller to handle the final XOR. > > Does the above solve your CRC problems? > Note also there is CRC32 code of this sort in WEP and TKIP crypto modules in the net80211 support. Sam