RE: [patch v5 resending 0/8] Add slicing-by-8 to crc32

["Bob Pearson" <rpearson@systemfabricworks.com>]

> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> Sent: Friday, August 12, 2011 1:40 AM
> To: Bob Pearson
> Cc: akpm@linux-foundation.org; fzago@systemfabricworks.com;
> linux@horizon.com; linux-kernel@vger.kernel.org
> Subject: Re: [patch v5 resending 0/8] Add slicing-by-8 to crc32
> 
> "Bob Pearson" <rpearson@systemfabricworks.com> wrote on 2011/08/11
> 19:52:01:
> >
> > Resending the patch series by hand. I have been having a lot of problems
> > trying to
> > Figure out how to make quilt and thunderbird play together. Please let
me
> > Know of this one is better. I have never been able to get quilt to
> > Make a mbox that my thunderbird likes but Frank has been able to do it.
> > The last time I imported a mbox into thunderbird as Unsent Messages and
> then
> > Edited each note and typed send but for some reason there was a lot of
> > breakage.
> > This time I just used the external editor to read in each patch from the
> > patches
> > Directory one a time.
> 
> I am not even going to try. After a quick look the still look broken and
> several my earlier remarks appears to be ignored.

I tried to apply the patches that you mentioned did not work to a fresh tree
and they were OK.

I will go through your emails again. I thought I had caught everything.
Since I went back to passing tab[][] to one common subroutine some of the
discussion points no longer applied. The one remaining point that was often
mentioned was your preferred form for the first loop. But in the last
exchange I thought we showed that ours was shorter. I did put in the
pointers as you suggest.

> The changes to gen_crc32table.c looks random, where did this come from
> (in v5 6/8):
>  -static uint32_t crc32table_le[4][LE_TABLE_SIZE];
> -static uint32_t crc32table_be[4][BE_TABLE_SIZE];
> +static uint32_t crc32table_le[4][256];
> +static uint32_t crc32table_be[4][256];

The table was declared as shown but is passed from main to output_table as
"uint32_t table[4][256]"

This causes a compiler warning because the types don't match. As it happens
the program prints out correct results because rows other than 0 are only
used of the column size is 256. I interpreted LE_TABLE_SIZE as the desired
size of the output table (which it is) and let the working table in
gen_crc32table.c be dimensioned at 256. I suppose that one could have
changed the dimension in output_table as well.



> 
>  Jocke