Re: [PATCH 2.6.1 -- take two] Add CRC32C chksums to crypto and lib routines
From: Clay Haapala (chaapala_at_cisco.com)
Date: 02/03/04
- Previous message: viro_at_parcelfarce.linux.theplanet.co.uk: "Re: module-init-tools/udev and module auto-loading"
- In reply to: Matt Mackall: "Re: [PATCH 2.6.1 -- take two] Add CRC32C chksums to crypto and lib routines"
- Next in thread: Matt Mackall: "Re: [PATCH 2.6.1 -- take two] Add CRC32C chksums to crypto and lib routines"
- Reply: Matt Mackall: "Re: [PATCH 2.6.1 -- take two] Add CRC32C chksums to crypto and lib routines"
- Reply: Matt Domsch: "Re: [PATCH 2.6.1 -- take two] Add CRC32C chksums to crypto and lib routines"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Matt Mackall <mpm@selenic.com> Date: Tue, 03 Feb 2004 13:13:48 -0600
On Tue, 3 Feb 2004, Matt Mackall uttered the following:
> On Tue, Feb 03, 2004 at 11:50:06AM -0600, Clay Haapala wrote:
>
>> + * 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?"
>
Take it up with Matt_Domsch@dell.com -- it's his code that I
cribbed, so that's the license line I used.
>> +#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.
>
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?
>> +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.
-- Clay Haapala (chaapala@cisco.com) Cisco Systems SRBU +1 763-398-1056 6450 Wedgwood Rd, Suite 130 Maple Grove MN 55311 PGP: C89240AD The marketing flacks who thought the Super Bowl half-time show was the best way to reach 25-49-year-old males - 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/
- Previous message: viro_at_parcelfarce.linux.theplanet.co.uk: "Re: module-init-tools/udev and module auto-loading"
- In reply to: Matt Mackall: "Re: [PATCH 2.6.1 -- take two] Add CRC32C chksums to crypto and lib routines"
- Next in thread: Matt Mackall: "Re: [PATCH 2.6.1 -- take two] Add CRC32C chksums to crypto and lib routines"
- Reply: Matt Mackall: "Re: [PATCH 2.6.1 -- take two] Add CRC32C chksums to crypto and lib routines"
- Reply: Matt Domsch: "Re: [PATCH 2.6.1 -- take two] Add CRC32C chksums to crypto and lib routines"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|