Re: rigth crc32 implementation

El Miércoles, 27 de Abril de 2005 04:57, Marcel Moolenaar escribió:
> On Apr 26, 2005, at 7:19 PM, Sam Leffler wrote:
> > Marcel Moolenaar wrote:
> >> On Tue, Apr 26, 2005 at 01:01:32PM -0700, Sam Leffler wrote:
> >>> Note also there is CRC32 code of this sort in WEP and TKIP crypto
> >>> modules in the net80211 support.
> >>
> >> Sam,
> >> Given the seperation of crc32() into crc32_raw() and crc32(), with
> >> either crc32() only or otherwise both functions inlined, are there
> >> any obstacles preventing the 802.11 code from using the ones in
> >> src/sys/libkern?
> >
> > The wep+tkip usage is integral to the cipher so splitting it out
> > would likely slow them and, more importantly, would also require
> > revalidation (there are test vectors but they're pretty limited).
> > These modules are self-contained for various reasons so I'm leary
> > of switching.
>
> Understood. Seems like a good reason to leave it as-is.
>
> >   I'll think about adding it under an #ifdef for those that want to
> > save 2Kbytes (the size of the crc tables).
>
> In my book, 2K isn't worth the trouble.
> Thanks for the info,

After some digging, seems that libkern crc32 is really a ether-II crc 
implementation, using the reflected tabbed alg.

The only difference I found is that the not reflected alg. is more usual 
and used, at last, in ueagle.

Only a latest thing about this rest.  Can be crc32_tab and his consumers 
alter to use a const definition?

uint32_t const crc32_tab[] = {
...

This will stop an ill defined module can alter the shared crc table.

Thanks in advance,
--
  josemi