Re: crypto: libcrc32c should select crc32c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux