From owner-freebsd-current Mon Aug 27 11:23:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0BFD437B401; Mon, 27 Aug 2001 11:23:35 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.5/8.11.5) with SMTP id f7RINVP44288; Mon, 27 Aug 2001 14:23:31 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 27 Aug 2001 14:23:31 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Baldwin Cc: Julian Elischer , current@FreeBSD.org Subject: RE: Headsup! KSE Nay-sayers speak up! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 27 Aug 2001, John Baldwin wrote: > > On 27-Aug-01 Julian Elischer wrote: > > I am ready to do my megga-commit to add the first stage of KSE-threading > > support > > to > > the kernel. If there is any argument as to the wisdom of this move, > > then this is the time to speak up! > > > > At this stage a commit would break alpha and ia64 until > > they are patched. From experience I can say that it's not a horrific > > change to the machine dependent code so patches PRE commit would be > > welcome. > > Just to get this out in the public: I for one think 5.x has enough > changes in it and would like for KSE to be postponed to 6.0-current and > 6.0-release. I know that I am in the minority on this, but wanted to > say it anyways. It doesn't mean I don't like the KSE work or anything > like that (I've even helped out on it some), I just think we have enough > work in our basket. Also, I'll point out that p4's merging abilities > make tracking current relatively easy, much more so than if Julian was > maintaining a separate tree with this patch and having to keep updating > current and manually merge it all the time. Well, I won't comment on the "minority" bit at all, but must admit I have reservations from a technical and management perspective. There seem to be a number of areas we need to carefully consider in the decision: (1) What impact will the KSE import have on SMPng development (both with respects to correctness and performance)? (2) What impact will KSE have on security (for many of the same correctness reasons as SMPng)? (3) What impact will KSE have on the 5.0-RELEASE schedule, and the time it takes for 5.x to get to "stable" world? Personally, I'm really excited to see the KSE work happening (really happening, not just talking about happening). We just need to make sure that we "do the right thing" with regards to the above (and other) points. A question I'm interested in answering, and haven't due to lack of experience, is to what extent p4 makes maintaining KSE in parallel (but not on the main branch) easier. I know that from the TrustedBSD perspective, CVS is a disaster as a tool for the three-tier development model. It would simply be infeasible to maintain the KSE work using CVS. Given that p4 is now available for this work, does that make a sufficient difference? One of the things I'm worried about here is that our spectrum of solutions to the KSE integration problem is a bit too black-and-white. Right now, the choice is presented as "KSE for 5.0-RELEASE, or not", where the "or not" is pretty sweeping. Is "KSE for 6.0-RELEASE, maintained as a parallel track" a real option? If so, that would probably be my preference, due to the risks identified above. But if postponing KSE from 5.0 means throwing out the effort, then we have a much harder choice. We need to make an objective choice here, weighing the needs of our users and developers, and to make that choice we need to be properly informed on the options. We need to make the decision in a timely manner, but we shouldn't rush it, because the risks of getting it wrong are very high. 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-current" in the body of the message