Re: [CryptoAPI-devel] testing...

[Herbert V. R. <hv...@hv...>]

On Mon, 2002-02-25 at 02:53, Kyle McMartin wrote:
> (sorry forgot to send this to the mailing list)
np :-)
=20
> > 1. how to automate the task of creating a kernel patch from the
> > cryptoapi-CVS? or maybe just do it like the frees/wan people do?

> This one should be easy, do all development in a HEAD branch, and when a
> new kernel is released, create a branch for it, and stabilize the
> branch, while all main work continues on HEAD.
well... the cryptoapi in it's current form should be version
independent! :-)

actually there's no sense for the tarball distro to carry a kernel
version number... only for the kernel patch distro...

the only annoying stuff that changes a bit is the top-level Makefile,
and some other minor bits in the build framework...
=20
> Only problem with this approach is releases for old kernels stagnates,
> so sticking to the stable tree, where people are nearly guaranteed to
> upgrade, is okay.
as said above, these scheme would apply, if the cryptoapi would mess
around with kernel internals which may change every version... but it's
quite self-contained.. it just adds source files; it doesn't modify
existing kernel source...
=20
> I'll suck down the cvs tree in a few minutes. Seeing how long it is
> taking for 2.4.18, I think shooting for a stable version for it would be
> a good idea, since at this rate it will be current for ages.
>=20
> I suppose coordination with the FreeS/WAN people would be a good idea,
> especially if they began using the CryptoAPI ciphers.
btw, so far the USAGI and a NFSv4 project is already using the
cryptoapi;
the frees/wan people are thinking about using it, but are a bit
disappointed about the current status...
=20
regards,
--=20
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: hv...@hv...       /    Finger hv...@gn... for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F
4142