Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S275525AbTHNUTE (ORCPT ); Thu, 14 Aug 2003 16:19:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S275529AbTHNUTE (ORCPT ); Thu, 14 Aug 2003 16:19:04 -0400 Received: from waste.org ([209.173.204.2]:44191 "EHLO waste.org") by vger.kernel.org with ESMTP id S275525AbTHNUTB (ORCPT ); Thu, 14 Aug 2003 16:19:01 -0400 Date: Thu, 14 Aug 2003 15:18:47 -0500 From: Matt Mackall To: James Morris Cc: Andrew Morton , Jeff Garzik , davem@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] cryptoapi: Fix sleeping Message-ID: <20030814201847.GO325@waste.org> References: <20030814071519.GJ325@waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1234 Lines: 32 On Fri, Aug 15, 2003 at 03:08:12AM +1000, James Morris wrote: > On Thu, 14 Aug 2003, Matt Mackall wrote: > > > It's basically trying to be friendly. Since we can't really detect > > when it's safe to do such yields, we should be explicitly flag the > > uses where its ok. Something like this: > > I think this is the best approach. > > > #define CRYPTO_TFM_MODE_MASK 0x000000ff > > #define CRYPTO_TFM_REQ_MASK 0x000fff00 > > -#define CRYPTO_TFM_RES_MASK 0xfff00000 > > +#define CRYPTO_TFM_RES_MASK 0x7ff00000 > > +#define CRYPTO_TFM_API_MASK 0x80000000 > > This doesn't leave much room for API flags -- the CRYPTO_TFM_REQ_MASK > could be made smaller. Leaves no room actually. I figured this would be easy to move around after the fact. On the subject of flags, what's the best way for an algorithm init function to get at the tfm structures (and thereby the flags) given a ctxt? Pointer math on a ctxt? -- Matt Mackall : http://www.selenic.com : of or relating to the moon - 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/