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>