On Sunday 2009-01-18 21:45, Sam Ravnborg wrote:
>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.[...]
>> >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?[...]
>> 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.
So what will the crypto subsystem try to do then, implementation-wise,
given that kbuild cannot be manually tuned this way?
--
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
