Date: Mon, 27 Aug 2001 18:28:16 -0500 From: Jim Bryant <kc5vdj@yahoo.com> To: Bosko Milekic <bmilekic@technokratis.com> Cc: Julian Elischer <julian@elischer.org>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Peter Wemm <peter@wemm.org>, Robert Watson <rwatson@FreeBSD.ORG>, current@FreeBSD.ORG Subject: Re: KSE kernel comparissons Message-ID: <3B8AD790.1050608@yahoo.com> References: <69957.998948345@critter> <Pine.BSF.4.21.0108271509190.74870-100000@InterJet.elischer.org> <20010827190504.A8647@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bosko Milekic wrote: > On Mon, Aug 27, 2001 at 03:09:53PM -0700, Julian Elischer wrote: > >>On Mon, 27 Aug 2001, Poul-Henning Kamp wrote: >> >> >>>In message <20010827204331.83656390B@overcee.netplex.com.au>, Peter Wemm writes: >>> >>> >>>>My personal check list before committing it to -current is: >>>>- an honest shot at getting the Alpha working. Shouldn't be too hard. >>>> I'll work on this if nobody else will. >>>>- finish the userland build stuff. >>>>- carefully reread all of the key diffs for i386/i386/*, kern/*, vm/* etc. >>>>- take a look at ports impact and prepare them for the landing. >>>> >>>If you add: >>> >>> - Beat the shit out of it together with other developers for a couple of >>> weeks. >>> >>>Then I'm all for committing it when you have checked off those boxes. >>> >>I agree with this list. >> > > I think that realistically speaking, after having looked over the > diff, and after considering what was discussed here, that it would be > a good time to introduce the KSE work done thus far some time soon, > after said testing is done. The reason for this is that the KSE > changes to date are, as Julian and some others mentionned, > "infrastructural changes," and not _functional_ changes. Therefore, I > don't expect them to create additional logic issues (e.g. "I wonder if > it's KSE's semantics that are breaking this..." shouldn't come up with > these changes when debugging other code). > Thus, I agree with Peter and Julian on this issue and will be > applying the diff to both dual CPU machines I have here and testing > tonight. At the same time, I do hope that the actual _functional_ > changes come in a hopefully more orderly/slower manner so that it is > in fact possible to track down logic problems w.r.t. KSE should they > arise. > > On another (perhaps unrelated) note, I've noticed on the lists at > least one or two -CURRENT users/testers insist on having KSE > functionality but at the same time expecting to have production > material in early 5.0 "releases." I find this to be disturbing. While > I do agree that earlier "5.0 releases" should deffinately reach out to > the largest userbase possible, I am concerned that some users will > perhaps expect so much from the system that they will immediately go > ahead and pit it against more mature SMP OSes out there and then go on > to complain about everything under the Sun because "brand new > functionality (X) is not what I expected." The robustness and > performance of the work being done now will become more and more > apparent only as things progress and it should be noted that all of > these "nice things" resulting from all the work we're presently doing > will not just all magically surface when 5.0-RC1 (or whatever it's > going to be called) is "released." As I recall, *total* "functionality" of the subsystems wasn't promised for 5.0-R, but the infrastructure *was* promised. I expect you are reponding to my post in the other thread... Nobody is expecting a kick-butt implementation to just spring from the head of Zeus, but the infrastructure should be in place so that a kick-butt implementation can be made from it in the time that follows. With the infrastructure in place, we can probably expect a good implementation by 5.1-R, if it doesn't get committed at this stage, Julian will be lucky to get it in by 6.0-R, and I bet all the same arguments against will come up then as well. The patches seem relatively benign, and after some basic immediate testing, they should be committed to -current. That's all I'm trying to say. My response to the other gentleman were to address his comments that FreeBSD should not even hit the goals it had set initially for 5.0. I disagree with those arguments completely. I thought that Jordan and the core team had a good, even pessimistic estimate a couple of years ago for the future of 5.0 and even 6.0 as I recall... IMHO, I would tend to say that those estimates were pessimistic even. It definitely wasn't a "everything, including the kitchen sink" philosophy such as they had for 2.0-R [which was also influenced by legal matters], a lot of people may still remember that release, and the mad rush to fix the newly-introduced problems afterwards, I'm certain that David Greenman and some others do :^) Expecting to see the base infrastructure in place with at least some functionality of the new infrastructure is being realistic. Expecting a *PERFECT* implementation and *FULL* functionality of the new paradigms isn't. I want to see a functional SMPng for sure, but Julian is right, now is the time for the KSE infrastructure to be committed, it's at that stage. Just clarifying my "clarification" here. BTW: shouldn't this be in the other thread? jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com 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?3B8AD790.1050608>