public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2004-02-03 19:13 UTC|newest]

Thread overview: 22+ 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 22:12   ` Clay Haapala
2004-01-16  1:40 ` Matt Mackall
2004-01-19 20:13 ` James Morris
2004-01-19 21:15   ` Clay Haapala
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 17:09         ` James Morris
2004-02-04 17:07           ` Clay Haapala
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 23:25                 ` Matt Domsch
2004-02-03 23:37                   ` Matt Mackall
2004-02-04 16:14                     ` Clay Haapala
2004-02-06 23:54                       ` Jamie Lokier
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox