Re: loop-AES supported ciphers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 28 Feb 2002, Marc Mutz wrote:
> Wrong. People start to accept is _now_. Take PPDD, take the NFS
> implementation announced Tuesday. CIPE and FreeS/WAN are at least
> considering the move.
btw, you forget to mention the USAGI Project @ http://www.linux-ipv6.org/
which already uses the API for their ipsec implementation
 
> Sorry, but that is how it works in Linux. I had to merge new-style RAID,
> ext3 and kerneli back when I built by own kernels (and I did that evry
> few days...)
know that well... had to do it with frees/wan, XFS, patch-int, 
ide-patch...

...wasn't there work ongoing in 2.5's kbuild framework to make merging 
easier? ;)

> > 	In other words if knowing what kernel version cryptoapi works
> > with can be more complicated than any kernel after version x.y.z,
> > then it will not be an easily deployable patch.
> No patch that adds a new API to the kernel applies to more than a few
> minor releases in a row. The kerneli patch on 2.2 was remarkable stable
> w.r.t. to applicability to different kernels. Now that 2.4 has somewhat
> settled, I expect that same to hold.

btw, the good thing about the cryptoapi right now is,

1.) that the API part itself lives in its own top-level subdir /crypto 
is quite self-contained:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cryptoapi/cryptoapi-core/crypto/
 
i.e. those files, get only added, so no patch conflicts can occur; and 
they are quite version indepent and

2.)
then there's the version dependent kbuild-patch, i.e. for 2.4.18
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/cryptoapi/cryptoapi-patches/linux-2.4/kbuild-2.4.18?rev=HEAD&content-type=text/plain

which I don't expect to change much in future 2.4.x versions

3.)
finally there's the optional loop.[ch] IV-fix patch, which really 
patches existing kernel source; this is version dependent as well, 
although the same patch applies to 2.4.1[678] so far...

==

btw, the reason I make a difference between 2.) and 3.) is, that 
loop-AES's patch conflicts with the simple loop-iv patch... and I want to 
leave the user the choice, which patch to use

> PS: Please trim your quotes.
:-)

-- 
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: hvr@hvrlab.org       /    Finger hvr@gnu.org for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F 4142

-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/



[Index of Archives]     [Kernel]     [Linux Crypto]     [Gnu Crypto]     [Gnu Classpath]     [Netfilter]     [Bugtraq]
  Powered by Linux