All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fruhwirth Clemens <clemens@endorphin.org>
To: Matt Mackall <mpm@selenic.com>
Cc: Fruhwirth Clemens <clemens-dated-1107431870.41eb@endorphin.org>,
	Andrew Morton <akpm@osdl.org>, James Morris <jmorris@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 04/04] Add LRW
Date: Sun, 30 Jan 2005 12:49:29 +0100	[thread overview]
Message-ID: <1107085769.13776.11.camel@ghanima> (raw)
In-Reply-To: <20050130000221.GA2955@waste.org>

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

On Sat, 2005-01-29 at 16:02 -0800, Matt Mackall wrote:
> On Mon, Jan 24, 2005 at 12:57:50PM +0100, Fruhwirth Clemens wrote:
> > This is the core of my LRW patch. Added test vectors.
> > http://grouper.ieee.org/groups/1619/email/pdf00017.pdf
> 
> Please include a URL for the standard at the top of the LRW code and
> next to the test vectors. I had to search around a fair bit for decent
> background material, would be helpful to a couple other references as
> well.

Ack.

> > +static inline void findAlignment(u128 callersN, int value, int *align) {
> > +	int i;
> 
> Your gfmulseq code has lots of StudlyCaps and strange whitespace, eg
> this '{' should be on the next line.

In fact, it's lowerCamelCase, that's intentional. The whitespace and the
left '{' is an error.

> > +	/* Copy N, so lsr does not destroy caller's copy */
> > +	u128_alloc(N);
> > +	copy128(N,callersN);
> 
> The usage of your u128 type is really confusing, so 'u128' is an
> especially bad name. I expect u128 to work like u64 and u32. I propose
> gf128_t.

That's ok.

> > +#define u128_alloc(VAR) u64 _ ## VAR ## _[2]; u128 VAR = _ ## VAR ## _
> 
> Wrap this in a struct, please. That's disgusting.

No need to be disgusted, I've seen much worse things in the kernel. I
will change it to C99 compound literals.

> > -obj-$(CONFIG_CRYPTO) += api.o scatterwalk.o cipher.o digest.o compress.o \
> > +obj-$(CONFIG_CRYPTO) += api.o scatterwalk.o cipher.o digest.o compress.o lrw.o gfmulseq.o \
> 
> LRW and the GF(2**128) code is not configurable?

No, it's a cipher mode. None of the modes is configurable.

-- 
Fruhwirth Clemens <clemens@endorphin.org>  http://clemens.endorphin.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2005-01-30 11:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-24 11:57 [PATCH 04/04] Add LRW Fruhwirth Clemens
2005-01-30  0:02 ` Matt Mackall
2005-01-30 11:49   ` Fruhwirth Clemens [this message]
2005-01-30 17:25     ` Matt Mackall
2005-01-31 15:47       ` James Morris
2005-01-30 12:26   ` James Morris

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=1107085769.13776.11.camel@ghanima \
    --to=clemens@endorphin.org \
    --cc=akpm@osdl.org \
    --cc=clemens-dated-1107431870.41eb@endorphin.org \
    --cc=jmorris@redhat.com \
    --cc=linux-kernel@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.