Date: Mon, 27 Aug 2001 15:13:19 -0500 From: Jim Bryant <kc5vdj@yahoo.com> To: Julian Elischer <julian@elischer.org> Cc: John Baldwin <jhb@FreeBSD.org>, current@freebsd.org Subject: Re: Headsup! KSE Nay-sayers speak up! Message-ID: <3B8AA9DF.8020000@yahoo.com> References: <XFMail.010827093406.jhb@FreeBSD.org> <3B8A7D66.22469D03@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > 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. >> >></stump> >> > > well I expected this to some extent.. > This is why I asked.. I want to get it out where it can be discussed. > the same could also be said for full pre-emption and SMP-NG. > > It is also interestingto note that KSE isn't the only game in town. > The new PTNG package looks interesting, using normal process rforking > to generate a pthreads environment. (It's a rewrite, not a port of > linux threads). > > All I have done is brought the kernel to a state where > it is READY for work to break the 1:1 barrier. It is basically > logically exactly the same kernel as in -current. I think it introduces > far fewer logical changes than, say, the pre-emption code, > or the locking code. I agree that we could wait. I don't however think we > should. I'd rather have ONE broken period than two. At USENIX we agreed that > if I got this done it would be committed and work could start to > provide the facilities that Dan and Chris need for the Userland > code to develop. Remember, that unless you turn this on, it's > a very complicated NOP. > > What P4 does is really irrelevent because there are only 4 people using it.. > (or is that 3?). It needs a distribution channel, and P4 isn't it. > (at least not at the moment.) > > What it DOES do however is make your locking code more challenging. > But that is going to have to be faced at some time.... Count my vote as a go-for-it. I agree that waiting for 6.0 would be too long indeed. I think that having the KSE framework in the kernel for 5.0 would be a good thing, along with SMPNG... I don't think this is going to turn into another 2.0-RELEASE fiasco [No offense, David, but 2.0-R was buggier than a bum's blanket], which, I may add, was quite quckly made stable after the initial -RELEASE. My one question is: If it does turn into another 2.0-R fiasco, are you ready to put in the hours needed to put out a QUICK bugfix -RELEASE [a la 5.0.5 or whatever?]. I would still prefer a stable -RELEASE. As far as intel goes, I say go for it! 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?3B8AA9DF.8020000>