>> We (KAME) are using 3.2-RELEASE and 2.2.8-RELEASE because we can't
>> base our IPv6 development on top of moving target.
>> FreeBSD 3.x-STABLE and 4.x are moving target (which moves very quickly)
>> and are unusable as base version for us - if we need to chase two
>> moving things (IPv6 and FreeBSD) we are doomed.
>Problem being is that the 2.2.x branch has been declared obsolete and dead
>by the Project.
>If serious development work is being done CURRENT has always been the
>targetted platform. But let's not nitpick about decissions make months
>earlier.
>However, 3.2-STABLE isn't that fast moving forward, and I doubt, based on
>earlier discussions about touching the 3.x branch, that Jordan will allow
>IPv6 to be entered into the 3.x branch (however TPTB may judge otherwise).
>So 4.x seems like the only alternative left...
I can't tell KAME users like: "Oh, if you would like to apply KAME
diffs you'll need to fetch FreeBSD 4.x of June 1st". KAME needs to
stick to x.y-RELEASE either, KAME have no choice anyways.
>And I am still working on that =)
Thanks for the effort!
>> There has been NRL/INRIA/KAME integration work going on (basically
>> to avoid "4 BSDs and 3 IPv6 = 12 choices" nightmare by making one
>> IPv6 stack). There are, mainly, some (or too many) management
>> issues there. We will be resolving management issues issue very soon,
>> hopefully by next week.
>That's good new ITOJUN-san, but I hope you can understand that after seeing
>OpenBSD deploy IPv6 and NetBSD-CURRENT getting the IPv6 code merged by you,
>that FreeBSD (read the userbase/developers) is anxious to also incorporate
>this.
I talked with [EMAIL PROTECTED] several times about IPv6/IPsec
integration, and the reaction was that:
FreeBSD can wait till unified-ipv6 is made available, since:
- IPv6 is not that urgent task and
- it will be messy if FreeBSD integrates KAME first,
then switch to unified-ipv6.
(making a big change twice for IPv6 is questionable route)
So we are in the current situation. (or maybe I was not pushing hard
enough)
NetBSD merged in KAME code last month, because NetBSD will have feature
freeze for 1.5 soon and needed IPv6 code earlier than that.
If I miss 1.5, it will not be able to be merged until 1.6 (planned to
be sometime late 2000, I heard). NetBSD will be switching to
unified codebase whenever it is made available (so NetBSD decided to
make a big change twice).
>> There's incomplete "unified" codebase there, which is not very
>> ready for public consumption. Anyway please hold till the managment
>> issue is resolved, I believe I can give you a good news.
>Let me ask one question: if a few of us got the 3.x kit of kame up to 4.x
>level and it got all commited would it make the `merged' stack easier to
>integrate into CURRENT or does the stack-project prefer to use a clean
>codebase? I myself think the first, which allows our driver writers time
>to adjust to IPv6 changes, get a lot of still-present bugs out and basically
>restabilize the system before the next IPv6 changes. Not to mention allow
>people to test/work with IPv6 already.
Here's my question: how much patch rejection you saw when
you tried to apply KAME/FreeBSD32 patch onto 4.0? Were there
many of these, or very few?
If they are very few, and core@freebsd is okay, I think KAME
can be merged into 4.0 tree first, then FreeBSD can switch
from KAME to unified whenever it becomes ready (just like NetBSD does).
Hopefully KAME and unified-ipv6 will not be that different,
except for dual-stack tcp part (KAME code used separate tcp4/tcp6
for a long time, due to maintenance and stability reasons. The way
unified code does dual-stack tcp is different from what KAME does).
Userland part can be reused without trouble.
There are, however, several drawbacks in doing that:
- Now we have multiple KAME/FreeBSD[34] repository, one is in
KAME site and one is in freefall.freebsd.org. Synchronizing
those tree is a big problem.
KAME already have problems synchronizing code between platforms
we support, the merge will increase the problem.
- Manpower issues. We need to continue providing KAME/FreeBSD32
anyways, for people who wants more stable IPv6/IPsec systems.
We can't just tell everybody to switch to 4.0 and chase
FreeBSD-current.
- We need some more FreeBSD commit privs for other KAME guys.
(this is a easy part)
- again, two big changes for IPv6? Impacts on IPv4 stability?
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
