[CryptoAPI-devel] Coding style, or something.

[Kyle M. <ky...@de...>]

I'm going to, after consensus, begin modifying the code to conform to
the standards that are the result of this thread.

Most of this is secondary and can wait until after a release...

To begin with, all code should follow the Linux kernels
Documentation/CodingStyle, with 8 space hard tabs (I need to convert the
code I've already written which uses soft tabs) and K&R style bracing.

However, the real problem is the lack of unification in the design of
the ciphers. A quick look into the ciphers/ direction reveals everything
is implemented with different variable names, etc. The code should be
modified to be uniform throughout.

I propose, therefore, that all cipher dependant code, be prefixed with
the name of the cipher, ie: a context for the cipher like bf_ctx, would
be Blowfish_CTX. Perhaps all cipher dependant defines, like KEYLEN,
BLOCKSIZE, etc. could be prefixed with the cipher name as well.

Now the more pressing matter, there are a number of patented and
GPL licensed modules in cryptoapi. If we wish to release and have people
integrate our code into their kernels (distributions, for example) we
must have the entire main cryptoapi package under the GPL or
dual-licensed. For example, Mandrake currently uses loop-AES, but would
be unable to include cryptoapi in their kernel, since we have patented and
non-free ciphers right there.

To remedy this, I propose a directory hierarchy extension to the
ciphers/ directory. For example, all free, mainline ciphers could stay
in their current place, and we could have cryptoapi-patented and
cryptoapi-nonfree extension tarballs which fill up ciphers/patented/ and
ciphers/non-free/

Comments, questions, flames?

  - k

--=20
copyleft (c) 2002, Kyle McMartin