Garrett D'Amore wrote: > Darren J Moffat wrote: >> It was on my suggestion that Tony use the kernel sys_shutdown variable >> because I've seen several other kernel/userland door services use this >> same variable to determine that they shouldn't fail because the system >> is shutting down. So I think there is plenty of sufficient, recently >> created, precedence for using this method. Also given they are in the >> same consolidation I don't see an issue since sys_shutdown is >> consolidation private (unless you can point me to an ARC case that >> says it is project private in which case we will seek a contract to >> use it). >> >> >> kcfd has two jobs and yes given the new system duty cycle scheduling >> class that part of kcfd's work could probably be done that way - >> however nothing in that part of kcfd is what motivates this change. >> However the other part of kcfd needs to remain in userland because we >> have no intention of pushing certificate parsing code down into the >> kernel. > > Fair enough. I still think the sys_shutdown check and corresponding > messaging should be made within the framework though, and not scattered > through each of the different modules.
Agreed on that part it should be a framework issue hidden behind crypto_register_provider and crypto_unregister_provider. -- Darren J Moffat
