From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1754138AbXDVHRd@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754138AbXDVHRd (ORCPT <rfc822;w@1wt.eu>);
	Sun, 22 Apr 2007 03:17:33 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754140AbXDVHRc
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 22 Apr 2007 03:17:32 -0400
Received: from nz-out-0506.google.com ([64.233.162.226]:18465 "EHLO
	nz-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754138AbXDVHRc (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 22 Apr 2007 03:17:32 -0400
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=AQf8T8/lk4Ntd5oXcFFXkFXOze7ts/gZh3idzQACwsA33UKwCO0hkVQNSCucwgBDfWrP3XJmD6s9Vr9PdNNaS0pL9tZVIOCHvto4tSnOilY3tV6Ayiu4APezZVrynGm409I3X2ERDRgAknsW8FkQaF/vXaLaJY6Vx8tt7OyspdI=
Message-ID: <a36005b50704220017y664eef89u5f78f1e089c5014@mail.gmail.com>
Date: Sun, 22 Apr 2007 00:17:31 -0700
From: "Ulrich Drepper" <drepper@gmail.com>
To: "William Lee Irwin III" <wli@holomorphy.com>
Subject: Re: [REPORT] cfs-v4 vs sd-0.44
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
       "Kyle Moffett" <mrmacman_g4@mac.com>, "Willy Tarreau" <w@1wt.eu>,
       "Ingo Molnar" <mingo@elte.hu>, "Con Kolivas" <kernel@kolivas.org>,
       linux-kernel@vger.kernel.org,
       "Andrew Morton" <akpm@linux-foundation.org>,
       "Nick Piggin" <npiggin@suse.de>, "Mike Galbraith" <efault@gmx.de>,
       "Arjan van de Ven" <arjan@infradead.org>,
       "Peter Williams" <pwil3058@bigpond.net.au>,
       "Thomas Gleixner" <tglx@linutronix.de>, caglar@pardus.org.tr,
       "Gene Heskett" <gene.heskett@gmail.com>
In-Reply-To: <20070422070238.GH2986@holomorphy.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070420140457.GA14017@elte.hu> <20070421154614.GA26169@elte.hu>
	 <20070421161818.GC7840@1wt.eu>
	 <alpine.LFD.0.98.0704210931370.9964@woody.linux-foundation.org>
	 <20070421164241.GF2986@holomorphy.com>
	 <E1192E83-5E64-4782-8F92-DDCA09CA2F55@mac.com>
	 <a36005b50704211249pb771b79k227914515b5f9906@mail.gmail.com>
	 <alpine.LFD.0.98.0704211634130.9964@woody.linux-foundation.org>
	 <a36005b50704211846g4ed1256fpad6a3a5670318314@mail.gmail.com>
	 <20070422070238.GH2986@holomorphy.com>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On 4/22/07, William Lee Irwin III <wli@holomorphy.com> wrote:
> I'm just looking for what people want the API to be here. With that in
> hand we can just go out and do whatever needs to be done.

I think a sched_yield_to is one interface:

   int sched_yield_to(pid_t);

For futex(), the extension is needed for the FUTEX_WAIT operation.  We
need a new operation FUTEX_WAIT_FOR or so which takes another (the
fourth) parameter which is the PID of the target.

For FUTEX_LOCK_PI we need no extension.  The futex value is the PID of
the current owner.  This is required for the whole interface to work
in the first place.