* Re: [ECOS] No zlib crc32 support?
@ 2003-12-09 21:08 Steve Strublic
2003-12-09 21:27 ` Gary Thomas
2003-12-10 8:39 ` Andrew Lunn
0 siblings, 2 replies; 15+ messages in thread
From: Steve Strublic @ 2003-12-09 21:08 UTC (permalink / raw)
To: ecos-discuss
Would there be any objection to including it (meaning the 'official' zlib version of crc32) in the
zlib package anyhow? In my case (and I would think many others), it makes what I'm doing completely
portable between Linux and eCos without having to ifdef for eCos.
Steve
--------
"Space is almost infinite. In fact, we think it is infinite." -- Dan Quayle
gary@mlbassoc.com
Sent by: To: SStrublic@hypercom.com
ecos-discuss-owner@sources cc: ecos-discuss@sources.redhat.com
.redhat.com Subject: Re: [ECOS] No zlib crc32 support?
12/09/03 01:45 PM
On Tue, 2003-12-09 at 13:25, Steve Strublic wrote:
> Hello all,
>
> I'm working on a little project to perform validation of a data set, and planned to use zlib's
crc32
> call to validate the data. Much to my surprise, I found that eCos does not support the crc32
> call--apparently, on purpose.
>
> Would someone be so kind as to explain why this is the case? I know I can use Adler32 as it's
> supported, but I'm just wondering why crc32 isn't supported.
Actually, I think it's just not duplicated in the ZLIB package.
CRC32 is available in the CRC package.
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] No zlib crc32 support?
2003-12-09 21:08 [ECOS] No zlib crc32 support? Steve Strublic
@ 2003-12-09 21:27 ` Gary Thomas
2003-12-10 8:39 ` Andrew Lunn
1 sibling, 0 replies; 15+ messages in thread
From: Gary Thomas @ 2003-12-09 21:27 UTC (permalink / raw)
To: Steve Strublic; +Cc: ecos-discuss
On Tue, 2003-12-09 at 14:04, Steve Strublic wrote:
> Would there be any objection to including it (meaning the 'official' zlib version of crc32) in the
> zlib package anyhow? In my case (and I would think many others), it makes what I'm doing completely
> portable between Linux and eCos without having to ifdef for eCos.
>
Are you wanting to call crc32() yourself? or use some of the ZLIB
functions (that aren't normally used by eCos) that require it?
If you're doing it, all you really need is:
#define crc32 cyg_crc32_accumulate
> Steve
>
> --------
> "Space is almost infinite. In fact, we think it is infinite." -- Dan Quayle
>
>
>
>
> gary@mlbassoc.com
> Sent by: To: SStrublic@hypercom.com
> ecos-discuss-owner@sources cc: ecos-discuss@sources.redhat.com
> .redhat.com Subject: Re: [ECOS] No zlib crc32 support?
>
>
> 12/09/03 01:45 PM
>
>
>
>
>
>
> On Tue, 2003-12-09 at 13:25, Steve Strublic wrote:
> > Hello all,
> >
> > I'm working on a little project to perform validation of a data set, and planned to use zlib's
> crc32
> > call to validate the data. Much to my surprise, I found that eCos does not support the crc32
> > call--apparently, on purpose.
> >
> > Would someone be so kind as to explain why this is the case? I know I can use Adler32 as it's
> > supported, but I'm just wondering why crc32 isn't supported.
>
> Actually, I think it's just not duplicated in the ZLIB package.
> CRC32 is available in the CRC package.
>
> --
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
>
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>
>
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] No zlib crc32 support?
2003-12-09 21:08 [ECOS] No zlib crc32 support? Steve Strublic
2003-12-09 21:27 ` Gary Thomas
@ 2003-12-10 8:39 ` Andrew Lunn
2003-12-10 11:14 ` [ECOS] " Daniel Néri
1 sibling, 1 reply; 15+ messages in thread
From: Andrew Lunn @ 2003-12-10 8:39 UTC (permalink / raw)
To: Steve Strublic; +Cc: ecos-discuss
On Tue, Dec 09, 2003 at 02:04:05PM -0700, Steve Strublic wrote:
> Would there be any objection to including it (meaning the 'official'
> zlib version of crc32) in the zlib package anyhow? In my case (and
> I would think many others), it makes what I'm doing completely
> portable between Linux and eCos without having to ifdef for eCos.
I took this and several other crc32 implementations out from various
bits of eCos simply because an image would end up with many
implementations in the same image. This is particularly bad because
each one had its own table of coefficients which is quite large and
totally redundant. eCos wants to be small so this was an obvious
optimization.
There was also the name space pollution problem. 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. So sorting this mess out i decide it was better to stick to
the standard cyg_ prefix convention.
I would be reluctant to put back the crc32 function in zlib. Its a
step back towards chaos, bigger images and potential naming problems.
Either do as Gary suggested, or call cyg_crc32().
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ECOS] Re: No zlib crc32 support?
2003-12-10 8:39 ` Andrew Lunn
@ 2003-12-10 11:14 ` Daniel Néri
2003-12-10 11:35 ` Andrew Lunn
0 siblings, 1 reply; 15+ messages in thread
From: Daniel Néri @ 2003-12-10 11:14 UTC (permalink / raw)
To: ecos-discuss
Andrew Lunn <andrew@lunn.ch> writes:
> I would be reluctant to put back the crc32 function in zlib. Its a
> step back towards chaos, bigger images and potential naming
> problems.
The recently released zlib 1.2.1 (not yet in eCos) has a new CRC32
implementation which is claimed to be about 50% faster than the old
one.
This would possibly be a good argument to at least make it
configurable which one to use. Or maybe even replace the eCos CRC32
implementation with the new one from zlib...
Regards,
--Daniel
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] Re: No zlib crc32 support?
2003-12-10 11:14 ` [ECOS] " Daniel Néri
@ 2003-12-10 11:35 ` Andrew Lunn
0 siblings, 0 replies; 15+ messages in thread
From: Andrew Lunn @ 2003-12-10 11:35 UTC (permalink / raw)
To: Daniel N?ri; +Cc: ecos-discuss
On Wed, Dec 10, 2003 at 12:14:44PM +0100, Daniel N?ri wrote:
> Andrew Lunn <andrew@lunn.ch> writes:
>
> > I would be reluctant to put back the crc32 function in zlib. Its a
> > step back towards chaos, bigger images and potential naming
> > problems.
>
> The recently released zlib 1.2.1 (not yet in eCos) has a new CRC32
> implementation which is claimed to be about 50% faster than the old
> one.
>
> This would possibly be a good argument to at least make it
> configurable which one to use. Or maybe even replace the eCos CRC32
> implementation with the new one from zlib...
I would probably go for replacing on the in the CRC package, but it
would depend on how they have made it faster.
Submit a patch and i will take a look.
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] No zlib crc32 support?
2003-12-15 17:56 [ECOS] " Steve Strublic
@ 2003-12-15 19:52 ` Nick Garnett
0 siblings, 0 replies; 15+ messages in thread
From: Nick Garnett @ 2003-12-15 19:52 UTC (permalink / raw)
To: Steve Strublic; +Cc: andrew, ecos-discuss
"Steve Strublic" <SStrublic@hypercom.com> writes:
> I'll leave the resolution up to the maintainers.
>
> Steve
Since Andrew is a maintainer, and the CRC stuff is his baby then I'm
quite happy to accept his judgement on this issue.
To largely reiterate what Andrew said: We cannot, as a general rule,
litter eCos with unqualified symbols like "crc32", we need to ensure
that the name space is a clean as possible for application
code. crc32() is not a standardized API function name, so we must call
it something else. Also, since there are several different CRC32
algorithms, selecting any specific implementation to be called crc32()
would never satisfy everyone. Making the user select the
implementation explicitly by means of a #define renders this choice
obvious.
--
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] No zlib crc32 support?
@ 2003-12-15 17:56 Steve Strublic
2003-12-15 19:52 ` Nick Garnett
0 siblings, 1 reply; 15+ messages in thread
From: Steve Strublic @ 2003-12-15 17:56 UTC (permalink / raw)
To: andrew; +Cc: ecos-discuss
I'll leave the resolution up to the maintainers.
Steve
--------
"Space is almost infinite. In fact, we think it is infinite." -- Dan Quayle
andrew@lunn.ch
To: SStrublic@hypercom.com
12/14/03 01:51 PM cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] No zlib crc32 support?
On Fri, Dec 12, 2003 at 09:49:39AM -0700, Steve Strublic wrote:
>
> Andrew, that's why I chose zlib's crc32 algorithm.
So you have chosen the algorithm. That algorithm happens to be
implemented by zlib as crc32 on unix like platforms. On eCos its
implemented by, according to you, cyg_ether_crc32_accumulate.
So we have no problems here.
> 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.
Why don't you think this is proper?
As far as im aware there is no standard covering this issue. The
proprietary library zlib is polluting the namespace by declaring this
function. This may cause problems in the future if POSIX do decide to
have a function called crc32() and decide to uses the POSIX crc
algorithm.
By using the names cyg_* i've deliberately avoided this namespace
pollution leaving the application and POSIX the ability to do what it
wants.
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] No zlib crc32 support?
2003-12-12 22:35 Steve Strublic
@ 2003-12-15 8:33 ` Andrew Lunn
0 siblings, 0 replies; 15+ messages in thread
From: Andrew Lunn @ 2003-12-15 8:33 UTC (permalink / raw)
To: Steve Strublic; +Cc: ecos-discuss
On Fri, Dec 12, 2003 at 09:49:39AM -0700, Steve Strublic wrote:
>
> Andrew, that's why I chose zlib's crc32 algorithm.
So you have chosen the algorithm. That algorithm happens to be
implemented by zlib as crc32 on unix like platforms. On eCos its
implemented by, according to you, cyg_ether_crc32_accumulate.
So we have no problems here.
> 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.
Why don't you think this is proper?
As far as im aware there is no standard covering this issue. The
proprietary library zlib is polluting the namespace by declaring this
function. This may cause problems in the future if POSIX do decide to
have a function called crc32() and decide to uses the POSIX crc
algorithm.
By using the names cyg_* i've deliberately avoided this namespace
pollution leaving the application and POSIX the ability to do what it
wants.
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] No zlib crc32 support?
@ 2003-12-12 22:35 Steve Strublic
2003-12-15 8:33 ` Andrew Lunn
0 siblings, 1 reply; 15+ messages in thread
From: Steve Strublic @ 2003-12-12 22:35 UTC (permalink / raw)
To: andrew; +Cc: andrew, ecos-discuss
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] No zlib crc32 support?
2003-12-10 16:14 Steve Strublic
2003-12-10 16:20 ` Gary Thomas
@ 2003-12-11 0:38 ` Andrew Lunn
1 sibling, 0 replies; 15+ messages in thread
From: Andrew Lunn @ 2003-12-11 0:38 UTC (permalink / raw)
To: Steve Strublic; +Cc: andrew, ecos-discuss
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] No zlib crc32 support?
@ 2003-12-10 16:22 Steve Strublic
0 siblings, 0 replies; 15+ messages in thread
From: Steve Strublic @ 2003-12-10 16:22 UTC (permalink / raw)
To: gary; +Cc: andrew, ecos-discuss
Gary/Andrew,
Works for me! Thanks for the info. I'll use cyg_crc32() as recommended.
Steve
--------
"Space is almost infinite. In fact, we think it is infinite." -- Dan Quayle
gary@mlbassoc.com
To: SStrublic@hypercom.com
12/10/03 09:20 AM cc: andrew@lunn.ch, ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] No zlib crc32 support?
On Wed, 2003-12-10 at 09:09, 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.
>
> 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.
>
> 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.
>
It's actually not up to eCosCentric, but rather the eCos maintainers :-)
In any case, we would never [intentionally] use a version which was not
compatible with the ZLIB version. The main reason for having it in the
separate CRC package, as Andrew pointed out, is so that there need only
be one copy in your application, whether you use ZLIB or just RedBoot or
whatever.
> Steve
>
> --------
> "Space is almost infinite. In fact, we think it is infinite." -- Dan Quayle
>
>
>
>
> andrew@lunn.ch
> To: SStrublic@hypercom.com
> 12/10/03 01:38 AM cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] No zlib crc32 support?
>
>
>
>
>
> On Tue, Dec 09, 2003 at 02:04:05PM -0700, Steve Strublic wrote:
>
> > Would there be any objection to including it (meaning the 'official'
> > zlib version of crc32) in the zlib package anyhow? In my case (and
> > I would think many others), it makes what I'm doing completely
> > portable between Linux and eCos without having to ifdef for eCos.
>
> I took this and several other crc32 implementations out from various
> bits of eCos simply because an image would end up with many
> implementations in the same image. This is particularly bad because
> each one had its own table of coefficients which is quite large and
> totally redundant. eCos wants to be small so this was an obvious
> optimization.
>
> There was also the name space pollution problem. 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. So sorting this mess out i decide it was better to stick to
> the standard cyg_ prefix convention.
>
> I would be reluctant to put back the crc32 function in zlib. Its a
> step back towards chaos, bigger images and potential naming problems.
>
> Either do as Gary suggested, or call cyg_crc32().
>
> Andrew
>
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] No zlib crc32 support?
2003-12-10 16:14 Steve Strublic
@ 2003-12-10 16:20 ` Gary Thomas
2003-12-11 0:38 ` Andrew Lunn
1 sibling, 0 replies; 15+ messages in thread
From: Gary Thomas @ 2003-12-10 16:20 UTC (permalink / raw)
To: Steve Strublic; +Cc: andrew, ecos-discuss
On Wed, 2003-12-10 at 09:09, 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.
>
> 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.
>
> 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.
>
It's actually not up to eCosCentric, but rather the eCos maintainers :-)
In any case, we would never [intentionally] use a version which was not
compatible with the ZLIB version. The main reason for having it in the
separate CRC package, as Andrew pointed out, is so that there need only
be one copy in your application, whether you use ZLIB or just RedBoot or
whatever.
> Steve
>
> --------
> "Space is almost infinite. In fact, we think it is infinite." -- Dan Quayle
>
>
>
>
> andrew@lunn.ch
> To: SStrublic@hypercom.com
> 12/10/03 01:38 AM cc: ecos-discuss@sources.redhat.com
> Subject: Re: [ECOS] No zlib crc32 support?
>
>
>
>
>
> On Tue, Dec 09, 2003 at 02:04:05PM -0700, Steve Strublic wrote:
>
> > Would there be any objection to including it (meaning the 'official'
> > zlib version of crc32) in the zlib package anyhow? In my case (and
> > I would think many others), it makes what I'm doing completely
> > portable between Linux and eCos without having to ifdef for eCos.
>
> I took this and several other crc32 implementations out from various
> bits of eCos simply because an image would end up with many
> implementations in the same image. This is particularly bad because
> each one had its own table of coefficients which is quite large and
> totally redundant. eCos wants to be small so this was an obvious
> optimization.
>
> There was also the name space pollution problem. 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. So sorting this mess out i decide it was better to stick to
> the standard cyg_ prefix convention.
>
> I would be reluctant to put back the crc32 function in zlib. Its a
> step back towards chaos, bigger images and potential naming problems.
>
> Either do as Gary suggested, or call cyg_crc32().
>
> Andrew
>
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] No zlib crc32 support?
@ 2003-12-10 16:14 Steve Strublic
2003-12-10 16:20 ` Gary Thomas
2003-12-11 0:38 ` Andrew Lunn
0 siblings, 2 replies; 15+ messages in thread
From: Steve Strublic @ 2003-12-10 16:14 UTC (permalink / raw)
To: andrew; +Cc: ecos-discuss
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.
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.
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.
Steve
--------
"Space is almost infinite. In fact, we think it is infinite." -- Dan Quayle
andrew@lunn.ch
To: SStrublic@hypercom.com
12/10/03 01:38 AM cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] No zlib crc32 support?
On Tue, Dec 09, 2003 at 02:04:05PM -0700, Steve Strublic wrote:
> Would there be any objection to including it (meaning the 'official'
> zlib version of crc32) in the zlib package anyhow? In my case (and
> I would think many others), it makes what I'm doing completely
> portable between Linux and eCos without having to ifdef for eCos.
I took this and several other crc32 implementations out from various
bits of eCos simply because an image would end up with many
implementations in the same image. This is particularly bad because
each one had its own table of coefficients which is quite large and
totally redundant. eCos wants to be small so this was an obvious
optimization.
There was also the name space pollution problem. 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. So sorting this mess out i decide it was better to stick to
the standard cyg_ prefix convention.
I would be reluctant to put back the crc32 function in zlib. Its a
step back towards chaos, bigger images and potential naming problems.
Either do as Gary suggested, or call cyg_crc32().
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [ECOS] No zlib crc32 support?
2003-12-09 20:29 Steve Strublic
@ 2003-12-09 20:45 ` Gary Thomas
0 siblings, 0 replies; 15+ messages in thread
From: Gary Thomas @ 2003-12-09 20:45 UTC (permalink / raw)
To: Steve Strublic; +Cc: ecos-discuss
On Tue, 2003-12-09 at 13:25, Steve Strublic wrote:
> Hello all,
>
> I'm working on a little project to perform validation of a data set, and planned to use zlib's crc32
> call to validate the data. Much to my surprise, I found that eCos does not support the crc32
> call--apparently, on purpose.
>
> Would someone be so kind as to explain why this is the case? I know I can use Adler32 as it's
> supported, but I'm just wondering why crc32 isn't supported.
Actually, I think it's just not duplicated in the ZLIB package.
CRC32 is available in the CRC package.
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 15+ messages in thread
* [ECOS] No zlib crc32 support?
@ 2003-12-09 20:29 Steve Strublic
2003-12-09 20:45 ` Gary Thomas
0 siblings, 1 reply; 15+ messages in thread
From: Steve Strublic @ 2003-12-09 20:29 UTC (permalink / raw)
To: ecos-discuss
Hello all,
I'm working on a little project to perform validation of a data set, and planned to use zlib's crc32
call to validate the data. Much to my surprise, I found that eCos does not support the crc32
call--apparently, on purpose.
Would someone be so kind as to explain why this is the case? I know I can use Adler32 as it's
supported, but I'm just wondering why crc32 isn't supported.
Thanks,
Steve Strublic
sstrublic@hypercom.com
--------
"Space is almost infinite. In fact, we think it is infinite." -- Dan Quayle
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2003-12-15 19:21 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-12-09 21:08 [ECOS] No zlib crc32 support? Steve Strublic
2003-12-09 21:27 ` Gary Thomas
2003-12-10 8:39 ` Andrew Lunn
2003-12-10 11:14 ` [ECOS] " Daniel Néri
2003-12-10 11:35 ` Andrew Lunn
-- strict thread matches above, loose matches on Subject: below --
2003-12-15 17:56 [ECOS] " Steve Strublic
2003-12-15 19:52 ` Nick Garnett
2003-12-12 22:35 Steve Strublic
2003-12-15 8:33 ` Andrew Lunn
2003-12-10 16:22 Steve Strublic
2003-12-10 16:14 Steve Strublic
2003-12-10 16:20 ` Gary Thomas
2003-12-11 0:38 ` Andrew Lunn
2003-12-09 20:29 Steve Strublic
2003-12-09 20:45 ` Gary Thomas
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 read-only IMAP folder(s) and NNTP newsgroup(s).