Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261569AbVDRKfH (ORCPT ); Mon, 18 Apr 2005 06:35:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262021AbVDRKfH (ORCPT ); Mon, 18 Apr 2005 06:35:07 -0400 Received: from hermes.domdv.de ([193.102.202.1]:47376 "EHLO hermes.domdv.de") by vger.kernel.org with ESMTP id S261569AbVDRKe7 (ORCPT ); Mon, 18 Apr 2005 06:34:59 -0400 Message-ID: <42638D53.9070809@domdv.de> Date: Mon, 18 Apr 2005 12:34:59 +0200 From: Andreas Steinmetz User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Vlasenko CC: Linux Kernel Mailinglist , jmorris@redhat.com, davem@davemloft.net, ak@suse.de, Herbert Xu Subject: Re: [RFC][PATCH 2/4] AES assembler implementation for x86_64 References: <4262B6E9.8040400@domdv.de> <200504181118.50594.vda@ilport.com.ua> <42637775.8000904@domdv.de> <200504181319.15708.vda@ilport.com.ua> In-Reply-To: <200504181319.15708.vda@ilport.com.ua> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1519 Lines: 51 Denis Vlasenko wrote: > On Monday 18 April 2005 12:01, Andreas Steinmetz wrote: > >>Denis Vlasenko wrote: >> >>>On Sunday 17 April 2005 22:20, Andreas Steinmetz wrote: >>> >>> >>>>The attached patch contains Gladman's in-kernel code for key schedule >>>>and table generation modified to fit to my assembler implementation, >>>>-- >>>>Andreas Steinmetz SPAMmers use robotrap@domdv.de >>> >>> >>>Patch contains a mix of several coding styles: >>> >>>+/* >>>+ * #define byte(x, nr) ((unsigned char)((x) >> (nr*8))) >>>+ */ >>>+inline static u8 >>>+byte(const u32 x, const unsigned n) >>>+{ >>>+ return x >> (n << 3); >>>+} >>> >>>what does const do here? >> >>Taken 'as is' from current kernel sources, i,e, crypto/aes.c > > > "It's a cut-n-paste" is not a good argument here. You > are adding a _new file_ with your patch, it's okay to clean > it up while doing this. IOW: do not dup the mess. > > OTOH, if _exactly the same file_ exist in i384 arch, then > you should not duplicate it at all. Find a way to use one file > for both arches. > > Note that this is only my view, I can be wrong. > -- > vda > I'll wait for Herbert Xu's review and his opinion on this. -- Andreas Steinmetz SPAMmers use robotrap@domdv.de - 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/