Hi Herbert, >> we can easily run them later on. However when the Bluetooth subsystem is >> built as module, then I would prefer to have the module loading fail in case >> one of the selftest fails. I can hack around this with a lot of ifdef config >> magic. If we would have all crypto, cipher etc. modules as crypto_initcall, >> then I would have to add nothing extra on my side. It would reduce the ifdef >> config magic on our side a lot. >> >> My personal take is that the crypto subsystem has become such a basic >> feature that it might make sense to ensure that all pieces (including >> ciphers) are loaded before we initialize any other subsystem. > > I don't think moving the crypto initcalls up is the answer because > moving the subsystem itself isn't enough if you actually want to > use crypto algorithms.
that is indeed true. All the crypto algorithm need to be moved as well. I considered that already since I had debugged the initcall order with a kernel without modules. > You'd need to move the algorithms too which would be a nightmare. Actually I was thinking to convert the algorithms to a newly introduced module_crypto_alg() and module_crypto_shash() helpers. This would be similar to module_usb_driver() and module_pci_driver(). And then changing the initcall level would be trivial. The module_init/module_exit is just all the same boilerplate anyway and we could get rid of it this way. Regards Marcel -- 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
