[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Dec 2013 10:30:40 -0500
From: Paul Gortmaker <paul.gortmaker@...driver.com>
To: Steven Rostedt <rostedt@...dmis.org>
CC: Thomas Gleixner <tglx@...utronix.de>,
Christoph Hellwig <hch@...radead.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] wait-simple: Introduce the simple waitqueue implementation
On 13-12-12 09:55 AM, Steven Rostedt wrote:
> On Thu, 12 Dec 2013 09:48:06 -0500
> Paul Gortmaker <paul.gortmaker@...driver.com> wrote:
>
>> 1) git mv wait.[ch] --- > cwait.[ch]
>> make an empty wait.h include cwait.h temporarily
>>
>> 2) rename all existing functions in cwait.[ch] to have an added
>> "c" prefix (or similar)
>>
>> in wait.h, temporarily add a bunch of things like
>> #define wait_xyz cwait_xyz
>> so that things still compile and link.
>
> What about instead change all users of wait_*() to cwait_*().
This might turn out to be a big patch, but it is largely
just a mechanical sed, so I guess that is OK.
>
> Then the next steps would be to skip 3 and jump right to 4)
>
>>
>> 3) track down the users who really need the extra complexity
>> and have them use cwait calls and include cwait.h
>>
>> 4) bring in the simple wait queue support as wait.c and wait.h
>> and delete the defines added in step two. This will be the
>> flag day commit.
>
> Not a flag day commit, as no one is using it. Then start converting all
> users back to the wait_*() functions one at a time. If something
> breaks, we know which one it was.
Yep, I think that would work and would avoid the flag day problem
that I was dreading.
Paul.
--
>
> -- Steve
>
>>
>> Is that what we want to do here?
>>
--
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