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

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

[Bob Pearson]

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.

[G.S.] Sorry but I managed to leave you off the list. They are out there in
case you
Don't subscribe to the whole list.

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Bob Pearson
> Sent: Wednesday, August 10, 2011 5:43 PM
> To: linux-kernel@vger.kernel.org; joakim.tjernlund@transmode.se;
> akpm@linux-foundation.org; linux@horizon.com;
> fzago@systemfabricworks.com
> Subject: [patch v5 0/8] Add slicing-by-8 to crc32
> 
> Changes for v5 (and hopefully last version)
> 	- added expanded version of document
> 	- added pointers to replace 2D table
> 	  references inside of loops
> 
> Signed-off-by: Bob Pearson <rpearson@systemfabricworks.com>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

[Joakim Tjernlund]

"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.
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];

 Jocke

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

[Bob Pearson]

> -----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

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

[Bob Pearson]

> 
> > 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.
> 

One more point I forgot when I wrote this. Output_table is used for both LE
and BE tables which could have different values for ?E_TABLE_SIZE. There is
no sensible choice for changing the declaration in output_table to try to
match the various table sizes. It is much simpler to just make the tables
"by 256" and leave it at that. Since this is a build time resource there is
no penalty for the kernel itself.

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

[Bob Pearson]

> I am not even going to try. After a quick look they still look broken

You are right, of course ;-) Patches 2, 6 and 7 each had one line in the
original with trailing whitespace.
Something in the process I used stripped the whitespace from the patch. I
will make another attempt and check them first. I miss the old days when I
could cat a file to sendmail. Thunderbird is hell and outlook which I am
required to use for most things is worse.

Thank you for your patience.

Bob