Date: Wed, 5 Jul 2000 11:48:04 +0100 (BST) From: Nick Hibma <n_hibma@calcaphon.com> To: Kris Kennaway <kris@FreeBSD.ORG> Cc: current@FreeBSD.ORG Subject: Re: KAME integration and plans Message-ID: <Pine.BSF.4.20.0007051147341.27253-100000@localhost> In-Reply-To: <Pine.BSF.4.21.0007050314090.84259-100000@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Could you mention the locations (as in a set of paths) that are hands-off? Nick On Wed, 5 Jul 2000, Kris Kennaway wrote: > 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 > -- n_hibma@webweaving.org n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ 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.20.0007051147341.27253-100000>