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.


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

Reply via email to