On Mon, Aug 20, 2007 at 12:16:18PM +0200, Andi Kleen wrote: > > The usual use case is: Somebody -- either admin or some command > implicitely -- executes modprobe aes because some text file > specifies the aes cipher. At least on my system that loads > the C version when both are enabled. modprobe will not load > multiple modules in this case. > > I don't think modprobe knows anything about these priorities. Right, in that case we'd only load one of them, usually the generic one since its name is what we're trying to load. > But that would require teaching the module loading user space > about all this first, right? That would be the best. However, it's not hard to do a simple probing in the kernel until modprobe(8) gets this feature. I'll code something up. > Also if one implementation is always better than the other > then I see little reason to ever have both. Well it's not that useful for an assembly implementation that works on all instances of a given architecture. However, one of the things we need to handle are drivers that only work on a subset of an architecture, such as padlock-aes. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
