Date: Mon, 27 Aug 2001 14:23:31 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Julian Elischer <julian@elischer.org>, current@FreeBSD.org Subject: RE: Headsup! KSE Nay-sayers speak up! Message-ID: <Pine.NEB.3.96L.1010827141515.42016P-100000@fledge.watson.org> In-Reply-To: <XFMail.010827093406.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010827141515.42016P-100000>