Prev: Run interrupt handlers always with interrupts disabled
Next: Winning Contact Code (AQ11WWRZZA1)!!!
From: Peter Zijlstra on 26 Mar 2010 06:10
Hi,

Would it make sense to clean up the set_cpus_allowed() vs
set_cpus_allowed_ptr() mess using the semantic patch tool?

I guess it would be three patches:
1) converting the current remaining set_cpus_allowed() users into
set_cpus_allowed_ptr().
2) remove set_cpus_allowed().
3) rename set_cpus_allowed_ptr() to set_cpus_allowed()



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Julia Lawall on 26 Mar 2010 07:30
On Fri, 26 Mar 2010, Peter Zijlstra wrote:

> Hi,
>
> Would it make sense to clean up the set_cpus_allowed() vs
> set_cpus_allowed_ptr() mess using the semantic patch tool?
>
> I guess it would be three patches:
> 1) converting the current remaining set_cpus_allowed() users into
> set_cpus_allowed_ptr().
> 2) remove set_cpus_allowed().
> 3) rename set_cpus_allowed_ptr() to set_cpus_allowed()

Perhaps a subtlety is that set_cpus_allowed is creating a new variable,
whose address it sends to set_cpus_allowed_ptr?

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 26 Mar 2010 08:00
On Fri, 2010-03-26 at 12:22 +0100, Julia Lawall wrote:
> On Fri, 26 Mar 2010, Peter Zijlstra wrote:
>
> > Hi,
> >
> > Would it make sense to clean up the set_cpus_allowed() vs
> > set_cpus_allowed_ptr() mess using the semantic patch tool?
> >
> > I guess it would be three patches:
> > 1) converting the current remaining set_cpus_allowed() users into
> > set_cpus_allowed_ptr().
> > 2) remove set_cpus_allowed().
> > 3) rename set_cpus_allowed_ptr() to set_cpus_allowed()
>
> Perhaps a subtlety is that set_cpus_allowed is creating a new variable,
> whose address it sends to set_cpus_allowed_ptr?

Yes it does that, but I don't think that actually matters,
set_cpus_allowed_ptr()'s arg is const, so making that temporary copy
shouldn't have any side effects.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Julia Lawall on 26 Mar 2010 12:40
I tried the following semantic patch:

@@
expression E1,E2;
@@

- set_cpus_allowed(E1, cpumask_of_cpu(E2))
+ set_cpus_allowed_ptr(E1, cpumask_of(E2))

@@
expression E;
identifier I;
@@

- set_cpus_allowed(E, I)
+ set_cpus_allowed_ptr(E, &I)

@@
@@

+BAD(
set_cpus_allowed(...)
+ )

I didn't get any occurrences of BAD in the output, so there seem to be
only calls to cpumask_of_cpu and identifiers. Looking at the result of
grepping for set_cpus_allowed suggested the same. Am I missing anything?

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: Run interrupt handlers always with interrupts disabled
Next: Winning Contact Code (AQ11WWRZZA1)!!!