Date: Wed, 15 Aug 2001 10:30:44 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: itojun@iijlab.net, net@freebsd.org Subject: Re: IPV6/KAME/protosw integration cleanup Message-ID: <Pine.NEB.3.96L.1010815100220.80130D-100000@fledge.watson.org> In-Reply-To: <3B777616.F70D384E@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Aug 2001, Julian Elischer wrote: > Robert Watson wrote: > > > > It strikes me that, although some code cleanup may be called for, a week > > is too agressive a deadline for many of them to be pushed through, > > especially in light of the code maintenance issue on the KAME side. > > I sugggest no changes in 4.x They have had over a year for cleaning it > up.. how much time do they need considering I've given them patches for > most of it.. Julian, I've taken a few minutes to review the archives of both the freebsd-net and freebsd-arch mailing lists, as well as the kame-snap mailings list. In the past three years worth of archives, I've found no evidence of you raising the ipprotosw-related issues. In fact, the only messages I found from you on the KAME list were cross-posts promoting netgraph, and the only posts on the -arch list relating to ipprotosw were from Yoshinobu Inoue requesting extensive review of changes he was making for KAME, to which you did not publically respond. In my experience, the KAME team has been responsive to both my questions and concerns regarding the IPv6 implementation, and so certainly my experience seems inconsistent with the sweeping assertions of un-responsiveness you have expressed; this is the experience of a number of other FreeBSD developers I have talked to concerning the KAME work in the past. While the KAME team is resource-constrained, they have been highly responsive. When working with the KAME team, it is necessary to make use of the appropriate forums, including *their* mailing lists. > > I > > suggest that we look at a more gradual approach, as there's no rush right > > now for 5.0-RELEASE, and attempt to address technical issues one at a time > > (rather than a mega-patch). This would allow changes to be integrated as > > necessary into the KAME tree one-by-one, allow synchronization with code > > on other platforms, and allow the resolution of any technical problems to > > be done in a manner that all consumers of the KAME code can accept. > > I've asked them to start working on it.. If they don't even start then > I'll act but if they start cleaning up the code (90% of the WARNING > messages we see in a kernel compile come from potential bugs introduced > with KAME) I'm happy to let them do it at their own pace.. as long as > there IS a pace. The KAME team faces a number of substantial hurdles in the task they have taken on, including the task of balancing concerns from a number of development communities other than ours. For them to realistically perform this task well, they need our cooperation and understanding of the problems they face. I'm not making a technical judgement of either their code or your changes here: I'm making an observation about the development process, and the real-world considerations that need to be made. If we want to continue to benefit from the KAME team's development efforts, we need to work with them, both to integrate their work into FreeBSD more tightly, and to contribute back to their efforts in a cooperative (and non-confrontational) manner. This means participating on the KAME mailing lists, and working with their developers to find solutions to the really hard problems, including the management of their development trees. Imagine for a moment you maintained Netgraph on the following platforms: FreeBSD, NetBSD, OpenBSD, Darwin, and BSD/OS. Each has subtly modified their network stacks, memory allocators, kernel threading and scheduling systems, and synchronization primitives. They've each made changes to the flags passed to a variety of routines, expectations for style compliance, and focus on memory and performance tradeoffs. Under those circumstances, the development of fundamentally new (and still, in many ways, experimental) technology is extremely challenging. And under those circumstances, you'd have substantial insight into the differences between the systems, and how to both manage code taking into account those differences in a resource-effective manner. This doesn't mean that you wouldn't change your code to respond to the needs of individual projects, just that your view of the world would reflect your circumstances, and that you'd attempt to find common ground. That search for common ground can only be performed with the censent of all the parties, through public discussion of the tradeoffs (and there will always be tradeoffs), and with patience rather than ultimatums. > > Increasing the differences between the FreeBSD and KAME trees will only > > serve to exacerbatese these difficilties, especially in light of other > > changes coming in on the FreeBSD side (such as fine-grained locking). We > > benefit a great deal from the work performed by the KAME team, and I think > > I speak for everyone on the FreeBSD side when I say that we certainly wish > > to continue to be able to take advantage of the KAME IP stack work :-). > > Sure, but we need to make sure that it sticks to quality goals. How for > example can you audit for correct function passing if they start using > random varargs in protocol modules? what if someone wants to use a > differnt combination of modules to those envisionned by the writers? No one is suggesting that quality goals should be sacrificed. What's being suggested is that KAME development naturally involves tradeoffs, and that in order to have the feature set they offer, we need to respect their ability to determine the necessary tradeoffs. That doesn't mean we can't attempt to change their minds about tradeoffs, possibly by presenting additional evidence, or working to build concensus with other KAME consumers, resolving some of the portability and consistency issues that currently present barriers. I won't challenge your view of architectural cleanliness: in the past, you've demonstrated high levels of competence in the area of architecture, and the ability to take on substantial challenges and come out with both clean and highly extensible abstractions. But you can't simply assert "this is the one true way, I'm committing in a week". To make assertions that the FreeBSD project mandates specific changes (of which you have made a number in your e-mails), you need to do a lot more concensus-building, and the KAME team needs to play a part in that, as they have substantial stakes in (and have made substantial contributions to) the network stack. Since your initial post, you've had a number of responses from the KAME team, both agreeing with some points and accepting changes, and noting that other points require further consideration in light of the code portability issues. They've offered you respectful and carefully thought out responses, taking into account your architectural concerns. We owe them similarly respectful (and non-confrontational) responses. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010815100220.80130D-100000>