On Thu, 2 May 2013, Derek Atkins wrote:
Benjamin Kaduk <[email protected]> writes:
Necessary is debatable. Desirable, well, all the reasons Debian tries
hard to eliminate bundled libraries. The kernel's crypto library (or
even an openssl krb5 backend) will offer aesni acceleration, which
hcrypto does not.
OpenAFS cannot use the Linux kernel's crypto because last I checked the
Linux KCrypto was GPLONLY, and OpenAFS was not GPL and therefore
couldn't use the API.
When I say "the kernel", I mean "the kernel that the openafs kernel module
is running in", which is by no means limited to linux. Certainly the
FreeBSD kernel (my personal choice) exposes crypto APIs to all loadable
modules; it appears that OS X does so as well if I am reading XCode
correctly.
I'm all for the initial implementation being hcrypto-only, but I think
that it makes sense to leave room for future expansion.
I think it's a reasonable goal, but it's going to require lots of
various plug-ins to support it on each platform/environment.
We know at build-time what platform is being targetted; I am imagining
that we would just build a platform-specific file instead of a common one,
to get the platform-specific features.
-Ben
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
