Could you mention the locations (as in a set of paths) that are


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
>, who provide a very simple way to establish a tunnel to
> the 6bone. Documentation is available on and related links.
> Kris
> --
> In God we Trust -- all others must submit an X.509 certificate.
>     -- Charles Forsythe <[EMAIL PROTECTED]>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

[EMAIL PROTECTED]                                          USB project

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to