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
>>>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
>>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 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!

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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to