Herbert Xu wrote: > In general we want to minimise the number of people who need to tweak > configuration parameters. I have nothing against a module parameter > that selected a specific fallback. However, if a large proportion of > people end up having to set the parameter once we get an assembly SHA > implementation (to either select it or deselect it) then we're doing > it wrong.
Then we could add a compile-time option (in Kconfig) for the default and set it to sha1-i586 once that is available. Or have a list of default fallbacks like sha1_fallback=sha1-i586,sha1-x86-64,sha1-generic. Neither is a big deal. I still favor this solution over the select_by_priority which seems a bit more fragile and less user-controllable/convenient. But it's just my feeling, nothing substantial ;-) How about the rest of the padlock patch? Any comments? Can I go ahead with the HW bits? For now I compile one padlock.ko with all AES, SHA1 and SHA256 support. I could split that into separate modules (or at least one for AES and one for SHA1+SHA256). Michal - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
