On Mon, May 22, 2006 at 04:19:28PM +1200, Michal Ludvig wrote: > > 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.
Compile-time options are usually bad since distros need generic kernels. Explicit fallbacks are going to be unwieldy. Anyway, there is nothing special about SHA in needing a fallback. Many hardware implementations will also need fallbacks. So we should be striving for a generic solution rather than ad-hoc ones. > 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 ;-) We can always have a priority-based default augmented with user-controlled settings (which can be implemented later on as the need arises). The main criterion for me is that the great majority of people shouldn't need to touch any settings. If they do, then we're doing something wrong. That of course does not preclude having knobs that allow people to tune things if they really want to. But ideally most people shouldn't need to bother with it. > 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). Sorry, I haven't had time to read it yet. I'll get back to you on that. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
