Re: crypto: libcrc32c should select crc32c

2009-01-19 Thread Herbert Xu
On Mon, Jan 19, 2009 at 08:51:49PM +0100, Jan Engelhardt wrote:

 So what will the crypto subsystem try to do then, implementation-wise,
 given that kbuild cannot be manually tuned this way?

Well if nobody wants to do the work to get the explcit dependencies
than I suggest that you hardcode this into your mkinitrd.

The patch you gave initially is unacceptable because it means
that most people will be stuck with the unoptimised version.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: crypto: libcrc32c should select crc32c

2009-01-18 Thread Sam Ravnborg
On Sun, Jan 18, 2009 at 09:14:16AM +0100, Jan Engelhardt wrote:
 
 On Sunday 2009-01-18 06:37, Herbert Xu wrote:
 On Sat, Jan 17, 2009 at 11:48:42PM +0100, Jan Engelhardt wrote:
 
  Looking at libcrc32c.c shows that it essentially depends on the
  crc32c crypto module, which was not packed into my initramfs image
  by mkinitrd because.. there is no dependency.
 
 Actually the whole point of doing the crc32c/libcrc32c reversal
 was to allow multiple providers of crc32c.  As it stands we have
 a generic C version plus an Intel version.
 
 So by applying yuor patch we'll go back to always using the C
 version which is unacceptable.
 
 I think a better way of tackling this is to note this information
 explicitly in the module.  For example, just like module aliases
 we can add explicit module dependencies.
 
 Can we?
 
 I was already thinking about it.. the Solaris kernel has
 its _depends_on variable for such things
 
   char _depends_on[] = crc32c;
 
 kbuild has something similar in its .mod.c files:
 
   static const char __module_depends[]
   __used
   __attribute__((section(.modinfo))) =
   depends=crc32c;
 
 But in kbuild, this functionality does not seem exported
 to me as a macro (maybe MODULE_DEPENDS?).

kbuild finds out during modpost what modules depends on what other modules
and this is used for the dependencies.
There is no way to control this manually today.

Sam


--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: crypto: libcrc32c should select crc32c

2009-01-17 Thread Herbert Xu
On Sat, Jan 17, 2009 at 11:48:42PM +0100, Jan Engelhardt wrote:

 Looking at libcrc32c.c shows that it essentially depends on the
 crc32c crypto module, which was not packed into my initramfs image
 by mkinitrd because.. there is no dependency.

Actually the whole point of doing the crc32c/libcrc32c reversal
was to allow multiple providers of crc32c.  As it stands we have
a generic C version plus an Intel version.

So by applying yuor patch we'll go back to always using the C
version which is unacceptable.

I think a better way of tackling this is to note this information
explicitly in the module.  For example, just like module aliases
we can add explicit module dependencies.  mkinitrd can then use
this for its computation.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html