Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758263AbXIBCj4 (ORCPT ); Sat, 1 Sep 2007 22:39:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753291AbXIBCjo (ORCPT ); Sat, 1 Sep 2007 22:39:44 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:37179 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753808AbXIBCjn (ORCPT ); Sat, 1 Sep 2007 22:39:43 -0400 Date: Sun, 2 Sep 2007 08:22:42 +0530 (IST) From: Satyam Sharma X-X-Sender: satyam@enigma.security.iitk.ac.in To: Herbert Xu cc: Andrew Morton , KAMEZAWA Hiroyuki , Linux Kernel Mailing List , Linux Crypto Mailing List Subject: Re: 2.6.23-rc4-mm1 In-Reply-To: <20070902014610.GA15533@gondor.apana.org.au> Message-ID: References: <20070831215822.26e1432b.akpm@linux-foundation.org> <20070901155353.8a09db69.kamezawa.hiroyu@jp.fujitsu.com> <20070831235815.a09c7865.akpm@linux-foundation.org> <20070901085429.GA7213@gondor.apana.org.au> <20070902014610.GA15533@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2363 Lines: 54 On Sun, 2 Sep 2007, Herbert Xu wrote: > > On Sun, Sep 02, 2007 at 02:39:15AM +0530, Satyam Sharma wrote: > > > > Tangential, but I've often wondered what are the upsides of keeping > > CONFIG_CRYPTO_ALGAPI as a separate config option in the first place? Every > > single item in crypto/ ends up "select"ing it (directly or transitively) > > so it makes all sense to just do away with it and keep it == CONFIG_CRYPTO > > in the Makefile, thusly: > > NACK. ALGAPI exists so that it can be built as a module, as > opposed to CRYPTO which is always built-in. I had already noticed that, and was even *expecting* you to reply with *exactly* this ;-) [ BTW CRYPTO is _not_ always built-in -- but only when CONFIG_CRYPTO=y ] Anyway, the natural follow-up to your argument is -- why is the other stuff in CRYPTO always built-in too ? Take the crypto_alloc_xxx() callchain for example (I chose it because it is the _first_ call any cryptoapi user ever has to make, and hence it's the one that deals with module-loading stuff). So what finally got exported out of crypto/ to the rest of the kernel was just the crypto_alloc_xxx() wrapper. That resolves to a call to crypto_alloc_base() in crypto/api.c, which first loads the specific low-level algo modules, and then proceeds to crypto_init_ops(), which itself may, say, resolve to a crypto_init_digest_ops() -- the only interface exported from digest.c. The point is, because the module-loading (if necessary) already takes place before the call to digest.c is made, there is _no_ reason why even digest.c can't be made modular -- or _any_ of the other CRYPTO stuff (with the exception of api.c itself, of course) that "always gets built-in" as you mentioned above. And so caring about the optimization of making ALGAPI modular rather than simply built-in with rest of "core" crypto stuff such as digest.c (which could _also_ have been made modular by the same logic but wasn't) sounds like a bogus argument to me. [ BTW did you notice that the __crypto_alloc_tfm() has been EXPORT_SYMBOL'ed _only_ because of one solitary modular-callsite in algapi.c ? ] Satyam - 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/