From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16980 invoked by alias); 12 Dec 2003 16:53:38 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 16968 invoked from network); 12 Dec 2003 16:53:37 -0000 Received: from unknown (HELO thing2.hypercom.com) (208.248.82.254) by sources.redhat.com with SMTP; 12 Dec 2003 16:53:37 -0000 Received: from Azphxn01.hypercom.com (azphxn01.hypercom.com [10.0.2.70]) by thing2.hypercom.com (8.12.7/8.12.7) with ESMTP id hBCGrUpN010179; Fri, 12 Dec 2003 09:53:30 -0700 (MST) To: andrew@lunn.ch Cc: andrew@lunn.ch, ecos-discuss@sources.redhat.com Message-ID: From: "Steve Strublic" Date: Fri, 12 Dec 2003 22:35:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: [ECOS] No zlib crc32 support? X-SW-Source: 2003-12/txt/msg00204.txt.bz2 Andrew, that's why I chose zlib's crc32 algorithm. On a technical note, I compared the output from crc32() from Linux's zlib with the output from the corresponding function in eCos, cyg_crc32_accumulate()... and they don't match. I did take into account the endian change from Linux on Intel versus eCos on PowerPC. I inspected the code for both implementations, and found that eCos's cyg_ether_crc32_accumulate() is the implementation that matches crc32() in zlib. The output from cyg_ether_crc32_accumulate() matches the output from zlib's crc32() under Linux after accounting for the endian change. Taking the crc32() implementation from zlib and including it in eCos... the output matches, of course. This is why I was initially concerned about not having crc32() as part of zlib in eCos. Andrew, you state... "The maintainers have no intention of changing these functions unless somebody can prove they are broken, which i think it very unlikely." I think I may have just proved that there's an issue. I don't think it's proper to have to #define 'crc32' as' cyg_ether_crc32_accumulate'. I'd prefer to hear the maintainers' position firsthand. Steve -------- "Space is almost infinite. In fact, we think it is infinite." -- Dan Quayle andrew@lunn.ch Sent by: To: SStrublic@hypercom.com ecos-discuss-owner@sources cc: andrew@lunn.ch, ecos-discuss@sources.redhat.com .redhat.com Subject: Re: [ECOS] No zlib crc32 support? 12/10/03 05:38 PM On Wed, Dec 10, 2003 at 09:09:53AM -0700, Steve Strublic wrote: > > Andrew, > >> "One of the crc32()functions actually implemented a different >> variation on the crc32() algorithm which was incompatible with all >> the other crc32 algorithms. Plus some "user" code may want to yet >> again implement its own crc32 algorithm." > This concerns me as a developer. I would hope that there would be > one supported CRC-32 algorithm; the one that is commonly accepted by > the general community, the one provided by zlib. It sounds like > what you're saying is that cyg_crc32() is to be that single > algorithm. There appears to be no commenly accepted crc32 algorithm. Instead there are at least two that i know off. There is cyg_crc32 which is what zlib uses and is also the same crc that Ethernet frames uses and probably other protocols. There is another well known one, cyg_posix_crc32 which is what the POSIX standards have specified. This is used by programs like cksum. There are other 32 bit algorithms, such as Adler, but i don't think this is actually a Cyclic Redundancy Check but some other algorithm. There are no standardized function names for these algorithms. 802.3 just specifies the algorithm, not its name. POSIX is the same as far as i know. > I have a setup where I generate binaries on a Linux machine. These > binaries are compressed/encrypted and then the output run through > CRC-32, and uploaded to the platform running eCos. The platform > then validates the encrypted binary by generating a CRC-32 value. > Obviously, the values must match. This is where my concern over > cyg_crc32() comes from. What you should really do if first specify what algorithm you want to use. This could be the ethernet CRC, POSIX CRC , hmac or anything else. Then find an implementation on both platforms. Doing it this way around guarantees it will work. Assuming a none standardized function name works the same on different platforms is dangerous. > As long as eCosCentric will guarantee that the output from > cyg_crc32() is and will remain 100% compatible with zlib's crc32(), > that works for me. The maintainers have no intention of changing these functions unless somebody can prove they are broken, which i think it very unlikely. Andrew -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss