From: Clay Haapala <chaapala@cisco.com>
To: Matt Mackall <mpm@selenic.com>
Cc: James Morris <jmorris@redhat.com>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
"David S. Miller" <davem@redhat.com>
Subject: Re: [PATCH 2.6.1 -- take two] Add CRC32C chksums to crypto and lib routines
Date: Tue, 03 Feb 2004 13:13:48 -0600 [thread overview]
Message-ID: <yqujad40j7rn.fsf@chaapala-lnx2.cisco.com> (raw)
In-Reply-To: <20040203185111.GA31138@waste.org> (Matt Mackall's message of "Tue, 3 Feb 2004 12:51:12 -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
next prev parent reply other threads:[~2004-02-03 19:13 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-14 21:31 [PATCH] Add CRC32C chksums to crypto routines Clay Haapala
2004-01-14 21:45 ` James Morris
2004-01-14 21:45 ` James Morris
2004-01-14 22:12 ` Clay Haapala
2004-01-14 22:12 ` Clay Haapala
2004-01-16 1:40 ` Matt Mackall
2004-01-19 20:13 ` James Morris
2004-01-19 20:13 ` James Morris
2004-01-19 21:15 ` Clay Haapala
2004-01-19 21:15 ` Clay Haapala
2004-01-19 21:33 ` James Morris
2004-01-19 21:33 ` James Morris
2004-02-03 16:58 ` [PATCH 2.6.1] Add CRC32C chksums to crypto and lib routines Clay Haapala
2004-02-03 16:58 ` Clay Haapala
2004-02-03 17:09 ` James Morris
2004-02-03 17:09 ` James Morris
2004-02-04 17:07 ` Clay Haapala
2004-02-04 17:07 ` Clay Haapala
2004-02-03 17:13 ` James Morris
2004-02-03 17:13 ` James Morris
2004-02-03 17:50 ` [PATCH 2.6.1 -- take two] " Clay Haapala
2004-02-03 18:51 ` Matt Mackall
2004-02-03 19:13 ` Clay Haapala [this message]
2004-02-03 19:27 ` Matt Mackall
2004-02-03 20:17 ` James Morris
2004-02-03 20:17 ` James Morris
2004-02-03 23:25 ` Matt Domsch
2004-02-03 23:37 ` Matt Mackall
2004-02-04 16:14 ` Clay Haapala
2004-02-04 17:21 ` Matt Mackall
2004-02-07 15:20 ` Matt Domsch
2004-02-18 21:24 ` Matt Domsch
2004-02-18 23:18 ` Matt Domsch
2004-02-06 23:54 ` Jamie Lokier
2004-02-04 2:18 ` James Morris
2004-02-04 2:18 ` James Morris
2004-02-04 3:11 ` Valdis.Kletnieks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yqujad40j7rn.fsf@chaapala-lnx2.cisco.com \
--to=chaapala@cisco.com \
--cc=davem@redhat.com \
--cc=jmorris@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mpm@selenic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.