Date: Wed, 5 Jul 2000 03:37:39 -0700 (PDT) From: Kris Kennaway <kris@FreeBSD.org> To: current@freebsd.org Subject: KAME integration and plans Message-ID: <Pine.BSF.4.21.0007050314090.84259-100000@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
As itojun has already posted, we are in the process of updating the
KAME IPv6/IPSEC code in FreeBSD to the latest KAME sources.
In importing the latest KAME code, we are not being too concerned about
whitespace or cosmetic diffs, unifdef'ing __NetBSD__ sections (at least in
userland) and so forth. The reason for this is that KAME is externally
maintained code, and so cosmetic differences in FreeBSD needlessly
complicate the diffs and really make life harder for merging. The KAME
team already have a difficult enough job in maintaining and developing the
code on 11 different BSD releases without us making life more difficult
for them by committing unneccessary code changes to FreeBSD.
In this vein, I'd like to suggest a new "hands-off" policy of not
committing gratuitous changes to KAME-derived code, including manpage
changes, unless:
a) The commit is required for operation on FreeBSD (in which case it's not
really gratuitous)
b) The commit is suitable for the other platforms KAME supports
as well, and is submitted back to KAME to be merged into their master
repo. If there are legitimate concerns with KAME code the place to get
them fixed is upstream, not in FreeBSD.
For example, the "hard sentence break" manpage sweeps should have been
submitted back to KAME, and the "remove unneeded #includes" should not
have touched the KAME code at all since it creates gratuitous diffs for no
functional change. X years down the line if the KAME project disbands, we
can do the FreeBSD style cleanups then.
At the moment I am not bothering to merge in gratuitous FreeBSD changes to
things like manpages, because we want to get this code into -current and
tested as quickly as possible. Sheldon Hearn will be taking care of
passing the manpage diffs back to KAME.
I intend to MFC this stuff in 4 or 5 days assuming it doesn't present any
problems, so this means we need everyone who is capable of doing so to
stress the new code as much as possible. IMO we *really* need to get this
into 4.1 despite the relatively short testing cycle, for the simple reason
that the newer code is much more functional, and in particular supports
the racoon IKE daemon for automatic management of IPSEFC security
associations (i.e. manually-keyed SAs are no longer required) - this is
already in ports. This is important for interoperability with other IPSEC
implementations.
I also would quite like to see ALTQ brought in - I have had lots of
support for this and so far no objections - although I forgot to ask
itojun not to unifdef that code before it was committed :-(. Perhaps if he
has time he'll commit that as well.
Userland binaries are not yet fully committed: the older binaries may not
work corectly with the new kernel code.
Anyone wanting to play with this stuff to help test it should check out
www.freenet6.net, who provide a very simple way to establish a tunnel to
the 6bone. Documentation is available on www.kame.net and related links.
Kris
--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <forsythe@alum.mit.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007050314090.84259-100000>