[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <459CB3E6.9080906@bull.net>
Date: Thu, 04 Jan 2007 08:59:34 +0100
From: Pierre Peiffer <pierre.peiffer@...l.net>
To: Ingo Molnar <mingo@...e.hu>
Cc: LKML <linux-kernel@...r.kernel.org>,
Dinakar Guniguntala <dino@...ibm.com>,
Jean-Pierre Dion <jean-pierre.dion@...l.net>,
Sébastien Dugué
<sebastien.dugue@...l.net>, Ulrich Drepper <drepper@...hat.com>,
Darren Hart <dvhltc@...ibm.com>
Subject: Re: [PATCH 2.6.19.1-rt15][RFC] - futex_requeue_pi implementation
(requeue from futex1 to PI-futex2)
Ingo Molnar a écrit :
> * Pierre Peiffer <pierre.peiffer@...l.net> wrote:
>
>> Ingo Molnar a écrit :
>>> looks good to me in principle. The size of the patch is scary - is there
>>> really no simpler way?
>> Humf, in fact, for the 64-bit part, I've followed the rule of the
>> existing 64-bit code in futex.c, which consists of duplicating all the
>> functions which can not be kept common, and add a suffix 64 to all
>> duplicated functions. Perhaps I missed something ?
>
> i dont think you missed anything - but some consolidation here would be
> nice. Only if possible of course :-)
Ok ;-)
So, you are not only speaking about "my" part of duplicated code, right ?
But, just for information, what is the sys_futex64 for, exactly ? Is there a
plan to have in the future a 64-bit PID ? Because for now, 32-bits futex is
enough, so... ?
Otherwise, I don't have a "clean" way to avoid this duplication.... :-/
--
Pierre Peiffer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists