From owner-cvs-all@FreeBSD.ORG Fri Jul 18 17:32:11 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2DA137B401; Fri, 18 Jul 2003 17:32:11 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D49A43F75; Fri, 18 Jul 2003 17:32:11 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc11) with ESMTP id <2003071900321001300miqu5e>; Sat, 19 Jul 2003 00:32:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA16734; Fri, 18 Jul 2003 17:32:09 -0700 (PDT) Date: Fri, 18 Jul 2003 17:32:07 -0700 (PDT) From: Julian Elischer To: "David O'Brien" In-Reply-To: <20030719001523.GA85201@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: deischen@FreeBSD.org cc: src-committers@FreeBSD.org cc: David Xu cc: cvs-src@FreeBSD.org cc: Scott Long cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libpthread Makefile src/lib/libpthread/test sigsuspend_d.c src/lib/libpthread/thread thr_cancel.c thr_concurrency.c thr_nanosleep.c thr_private.h thr_sig.c thr_sigmask.c ... X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2003 00:32:12 -0000 On Fri, 18 Jul 2003, David O'Brien wrote: > > Who are "the arches"? KSE is a new feature, so the responsibility is on > the KSE developers to complete their implementation on all Tier-1 > platforms. I've offered Alpha boxes to all the KSE developers and have > had zero takers... (same for i386 SMP boxes... but that's another story) > I dont know the alpha and having a box isn't going to help that. I can "guide" soemone who DOES know it as to what the kernel MD parts should do but I'm not in a position to code them. They are pretty trivial to describe, but you need to know a lot about the architecture in question to know how each function should be achieved. I guess what I should do is produce a recipe as to what needs to be added to to each architecture's MD files to 'complete' that architecture. With that I think specialists in each architecture should have little problem filling in the gaps.