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 11:50:06AM -0600, Clay Haapala wrote:

> +void crypto_exit_chksum_ops(struct crypto_tfm *tfm)
> +{
> +	return;
> +}

It'd be nice to come up with a way to avoid null funcs just for the
sake of satisfying function pointers, there's quite a few of them
around.

> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the Free
> + * Software Foundation; either version 2 of the License, or (at your option) 
> + * any later version.
...
> +MODULE_LICENSE("GPL and additional rights");

"additional rights?"

> +#if __GNUC__ >= 3	/* 2.x has "attribute", but only 3.0 has "pure */
> +#define attribute(x) __attribute__(x)
> +#else
> +#define attribute(x)
> +#endif

This sort of thing ought to be added to linux/compiler.h if it's not
there already.

> +/*
> + * 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.

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

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