Re: [PATCH 2.6.1 -- take two] Add CRC32C chksums to crypto and lib routines

[Matt Mackall <mpm@selenic.com>]

On Tue, Feb 03, 2004 at 01:13:48PM -0600, Clay Haapala wrote:
> On Tue, 3 Feb 2004, Matt Mackall uttered the following:
> 
> +/*
> + * Haven't generated a big-endian table yet, but the bit-wise version
> + * should at least work.
> + */
> > 
> > Big-endian in this context means, of course, the order of the bits in
> > the byte rather than bytes in a word, and as this CRC polynomial was
> > chosen especially for its robustness on noise bursts in little-endian
> > transmission (aka standard serial and network *bit* transmission
> > ordering), I think we should intentionally omit BE support and make
> > note of it.
> > 
> Yes, it is about transmission bit-order.  Is the crc32 BE code also
> not necessary?  Does it deal with how various networking hardware
> and architecture combos present this data?

The crc32_be stuff is used by at least Bluetooth, some of the digital
video stuff, and a couple other random things. I suspect it's mostly
historical accident.

> >> +static inline void crypto_chksum_final(struct crypto_tfm *tfm, u32 *out)
> >> +{
> >> +	BUG_ON(crypto_tfm_alg_type(tfm) != CRYPTO_ALG_TYPE_CHKSUM);
> > 
> > A lot of these BUG_ONs seem to be overkill. You're not going to get
> > here by someone accidentally misusing the interface. You can only get
> > here by some very willful abuse of the interface or by extremely
> > unlikely fandango on core, neither of which is worth trying to defend
> > against.
> 
> That would be a worth changing in a clean-up pass over all of
> crypto, then.

I'll do them if James has no objections. I've got a couple other
crypto bits queued.

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting