Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Aug 2001 10:39:21 -0700 (PDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Daniel Eischen <eischen@vigrid.com>
Cc:        current@FreeBSD.org, Julian Elischer <julian@elischer.org>
Subject:   RE: Headsup! KSE Nay-sayers speak up!
Message-ID:  <XFMail.010827103921.jhb@FreeBSD.org>
In-Reply-To: <Pine.SUN.3.91.1010827124318.21541A-100000@pcnet1.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On 27-Aug-01 Daniel Eischen wrote:
> 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.
> 
> I think waiting for 6.0-current is too long.  Perhaps after 5.0-release.
> If we get this in 5.0, we might be able to have a usable kse threads
> library for 5.1 or 5.2.

I'm predicting a short release cycle between 5.0 and 6.0 (compared to 4.0 and
5.0) because 6.0 is probably going to be much more stable than 5.x.

> I've used p4 to track the CAM changes before they were in -current.  It 
> was initially easy when only the kernel was involved, but once userland
> was was touched I ended up having to use p4 to track everything else.
> At the time I didn't have enough disk space to have both a CVS src/
> tree and a p4 tree.  Plus it's difficult when you have more than one
> development system because you can't just keep one CVS repo and update
> all your systems from that.

NFS works for that (it's what I do with all my development systems, one shared
kernel souce tree over NFS with various p4 kernel sys trees checked out). 
However, I agree adding userland into the mix will complicate things.

-- 

John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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?XFMail.010827103921.jhb>