crypto api initialized late

[Reiner Sailer <sailer@us.ibm.com>]

I am writing a Linux Security Module that needs SHA1 support very early in 
the kernel startup (before any fs are mounted,modules are loaded,  or 
files are mapped; including initrd). Therefore, I use the __initcall 
to initialize the security module. SHA1 can currently be used only 
through the crypto-api (static definitions and hidden context structure).

This crypto-API, however, initializes AFTER the security module
code in the __initicall block. Currently, I use the following patch into 
the main Linux Makefile to start up the crypto-API earlier:

diff -uprN linux-2.6.12-rc3_orig/Makefile 
linux-2.6.12-rc3-ima-newpatch/Makefile
--- linux-2.6.12-rc3_orig/Makefile	2005-04-20 20:03:12.000000000 -0400
+++ linux-2.6.12-rc3-ima-newpatch/Makefile	2005-05-11 15:18:32.000000000 -0400
@@ -560,7 +560,7 @@ export MODLIB


  ifeq ($(KBUILD_EXTMOD),)
-core-y		+= kernel/ mm/ fs/ ipc/ security/ crypto/
+core-y		+= kernel/ mm/ fs/ ipc/ crypto/ security/

  vmlinux-dirs	:= $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \
  		     $(core-y) $(core-m) $(drivers-y) $(drivers-m) \


Generally, I can think of the following solutions:
a) initialize crypto api in a initblock earlier than __initcall
b) make crypto functions global in the kernel and make crypto-api
    usage optional (goes against the idea of the api)
c) re-implement SHA1 for my LSM (won't be accepted)
d) the above patch (acceptable?)

Is there a preferred/accepted way to handle this startup-sequence problem?

Reiner