Resolving the crypto duplicity...

[Poul-Henning Kamp]

In message <200402042324.18434.sam at errno.com>, Sam Leffler writes:

>All the cipher code in opencrypto is there for a reason; either because it ran 
>substantially faster than the KAME code at the time I imported the crypto 
>framework or because there were API incompatbilities that made using the KAME 
>versions difficult. In general the one overriding rule I had was that I could 
>not remove any code in crypto so anything new had to go in opencrypto.

If we collapse the two, we should of course keep the best version.

I guess my suggestion/question could also be put this way: "Is it
about time we stop having a 'KAME crypto' and a 'OpenCrypto' code
set, and instead get us a 'FreeBSD crypto' code set.

>I tried to get opencrypto included in GENERIC for 5.2 but was too late.  I 
>think making it part of the base system is too costly for embedded 
>environments but could be persuaded otherwise.
>
>I think with your recent mods that gbde depends on opencrypto so I'm not sure 
>why you're worried about an explicit rijndael dependency unless you can build 
>gbde w/ and w/o the opencrypto usage.

Well, my problem is that either I need a compiletime #ifdef to decide to
pull in opencrypto support, or we need to add failing stub-functions when
we do not have opencrypto in the kernel.

I would really like to avoid the situation where I have to have two
different gbde kld's: one with and one without opencrypto.

But as I said, it may be time to discuss the overall issue of kld
dependencies, rather than just scratch my own little itch...

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.