From: Julia Lawall <julia@diku.dk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Yinghai Lu <yinghai@kernel.org>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
Suresh Siddha <suresh.b.siddha@intel.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 06/12] genericirq: make irq_chip related function to take desc
Date: Sun, 21 Mar 2010 15:19:58 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.4.64.1003211515310.12371@ask.diku.dk> (raw)
In-Reply-To: <m1iq8p23af.fsf@fess.ebiederm.org>
On Sun, 21 Mar 2010, Eric W. Biederman wrote:
> Julia Lawall <julia@diku.dk> writes:
>
> > I also worked on this, but only sent it to Thomas and Yinghai. Onthe
> > other hand, I mostly like your solution better, because it has the
> > unintended side-effect of getting rid of some blank spaces after {s.
>
> Wow I hadn't noticed that {s removal. That is an old coding style
> violation on alpha. There was an intentional effect of not breaking
> up { }'s. But I hadn't realized I was also fixing whitespace.
I think it is because you added a local declaration of irq and then
removed it when it was not necessary. So then coccinelle was motivated to
remove the space after the {.
> > My rule was also more complicated in that it also searches for conditions
> > in which it is not sure to be doing the right thing. I will send those in
> > another message.
> >
> >> @ DECL @
> >> struct irq_chip CHIP;
> >> identifier METHOD;
> >> identifier METHOD_NAME;
> >> @@
> >> CHIP.METHOD_NAME = METHOD;
> >>
> >> @ @
> >> identifier DECL.METHOD;
> >> identifier IRQ;
> >> @@
> >> METHOD(
> >> - unsigned int IRQ
> >> + struct irq_desc *unused
> >> , ...) {
> >> }
> >
> > I didn't think of making a special rule for this. It could consider any
> > case where the body is ... when != IRQ
>
> Nice addition.
>
> >> @ @
> >> identifier DECL.METHOD;
> >> identifier IRQ;
> >> identifier DESC;
> >> @@
> >> METHOD(
> >> - unsigned int IRQ
> >> + struct irq_desc *DESC
> >> , ...) {
> >> + unsigned int IRQ = DESC->irq;
> >> ...
> >> - struct irq_desc *DESC = irq_to_desc(IRQ);
> >> ...
> >> }
> >>
> >> @ @
> >> identifier DECL.METHOD;
> >> identifier IRQ;
> >> identifier DESC;
> >> @@
> >> METHOD(
> >> - unsigned int IRQ
> >> + struct irq_desc *DESC
> >> , ...) {
> >> + unsigned int IRQ = DESC->irq;
> >> ...
> >> - struct irq_desc *DESC;
> >> ...
> >> - DESC = irq_to_desc(IRQ);
> >> ...
> >> }
> >>
> >> @ @
> >> identifier DECL.METHOD;
> >> identifier IRQ;
> >> @@
> >> METHOD(
> >> - unsigned int IRQ
> >> + struct irq_desc *desc
> >> , ...) {
> >> + unsigned int IRQ = desc->irq;
> >> ...
> >> }
> >>
> >> @ @
> >> identifier DECL.METHOD;
> >> identifier FUNC;
> >> identifier IRQ;
> >> @@
> >> FUNC(...) {
> >> <...
> >> METHOD(
> >> - IRQ
> >> + irq_to_desc(IRQ)
> >> , ... )
> >> ...>
> >> }
> >
> > I don't think FUNC(...) { <... and ...> } are needed here. The goal is to
> > make the change everywhere the call appears.
>
> That is a reasonable simplification.
>
> >> @ @
> >> identifier FUNC;
> >> identifier DESC;
> >> identifier IRQ;
> >> @@
> >> FUNC(..., struct irq_desc *DESC, ...) {
> >> ...
> >> unsigned int IRQ = DESC->irq;
> >> <...
> >> - irq_to_desc(IRQ)
> >> + DESC
> >> ...>
> >> }
> >
> > This rule can be extended as follows:
>
> Nice. I had not picked up on the or operator.
>
> > @ @
> > identifier FUNC;
> > identifier DESC;
> > identifier IRQ;
> > identifier FLD;
> > @@
> > FUNC(..., struct irq_desc *DESC, ...) {
> > ...
> > unsigned int IRQ = DESC->irq;
> > <...
> > (
> > - irq_to_desc(IRQ)
> > + DESC
> > |
> > - irq_desc[IRQ].FLD
> > + DESC->FLD
> > )
> > ...>
> > }
> >
> > Doing so gets rid of more references to IRQ.
>
> Very reasonable, especially on arches like alpha where none of the
> sparse irq work has hit.
>
>
> > Another case that can be treated is method calls via a pointer:
>
> I didn't actually find any cases where that rule hit on arch/x86
> so I did not include it, but it makes sense.
>
> > @@
> > expression arg;
> > struct irq_desc *desc;
> > struct irq_chip *ic;
> > identifier fun;
> > @@
> >
> > (
> > desc->chip->fun(
> > - arg
> > + desc
> > ,...)
> > |
> > ic->fun(
> > - arg
> > + irq_to_desc(arg)
> > ,...)
> > )
>
>
> My paranoid sense says this rule should be:
> @ @
> expresion IRQ_EXPR;
> struct irq_desc *DESC;
> struct irq_chip *CHIP;
> identifier METHOD;
> @@
> (
> DESC->chip->METHOD(
> - IRQ_EXPR
> + irq_to_desc(IRQ_EXPR)
> , ... )
> |
> CHIP->METHOD(
> - IRQ_EXPR
> + irq_to_desc(IRQ_EXPR)
> , ... )
Agreed. But then it would be nice to check whether DESC is already
computed as irq_to_desc(IRQ_EXPR).
julia
> If this is before my irq_to_desc removal rule. We should not
> see any new irq_to_desc calls popping up.
>
> > julia
> >
> >> @ @
> >> identifier FUNC;
> >> identifier DESC;
> >> identifier IRQ;
> >> @@
> >> FUNC(..., struct irq_desc *DESC, ...) {
> >> ...
> >> - unsigned int IRQ = DESC->irq;
> >> ... when != IRQ
> >> }
>
next prev parent reply other threads:[~2010-03-21 14:20 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-04 10:08 [PATCH 0/12] irq related: make function to take irq_desc pointer instead of irq Yinghai Lu
2010-03-04 10:08 ` [PATCH 01/12] x86: fix out of order of gsi - full Yinghai Lu
2010-03-04 10:08 ` [PATCH 02/12] x86: set nr_irqs_gsi only in probe_nr_irqs_gsi Yinghai Lu
2010-03-04 10:08 ` [PATCH 03/12] x86: kill smpboot_hooks.h Yinghai Lu
2010-03-04 10:08 ` [PATCH 04/12] x86: use vector_desc instead of vector_irq Yinghai Lu
2010-03-04 10:08 ` [PATCH 05/12] genericirq: make irq_chip to have member with irq_desc pointer Yinghai Lu
2010-03-04 10:08 ` [PATCH 06/12] genericirq: make irq_chip related function to take desc Yinghai Lu
2010-03-04 14:31 ` Thomas Gleixner
2010-03-04 18:56 ` Yinghai Lu
2010-03-04 19:08 ` Thomas Gleixner
2010-03-04 19:20 ` Yinghai Lu
2010-03-05 7:47 ` Julia Lawall
2010-03-21 4:18 ` Eric W. Biederman
2010-03-21 11:03 ` Julia Lawall
2010-03-21 13:11 ` [PATCH] irq: Start the transition of irq_chip methods taking a desc Eric W. Biederman
2010-03-21 14:43 ` Thomas Gleixner
2010-03-21 18:50 ` Yinghai Lu
2010-03-22 0:32 ` Eric W. Biederman
2010-03-21 13:49 ` [PATCH 06/12] genericirq: make irq_chip related function to take desc Eric W. Biederman
2010-03-21 14:19 ` Julia Lawall [this message]
2010-03-21 16:29 ` Julia Lawall
2010-03-21 11:08 ` Julia Lawall
2010-03-21 11:43 ` Eric W. Biederman
2010-03-21 19:16 ` Julia Lawall
2010-03-21 19:35 ` Julia Lawall
2010-03-21 19:36 ` Julia Lawall
2010-03-22 0:36 ` Eric W. Biederman
2010-03-04 19:18 ` Yinghai Lu
2010-03-04 10:08 ` [PATCH 07/12] genericirq: make hpet_msi/ht/msi/dmar_msi " Yinghai Lu
2010-03-04 10:08 ` [PATCH 08/12] x86: make irq_chip to use desc_mask instead of mask Yinghai Lu
2010-03-04 15:10 ` [PATCH 08/12] x86: make irq_chip to use desc_mask instead of maskn Thomas Gleixner
2010-03-04 10:08 ` [PATCH 09/12] x86: irq_chip to use desc_mask instead of mask part 2 Yinghai Lu
2010-03-04 10:08 ` [PATCH 10/12] genericirq: add set_irq_desc_chip/data Yinghai Lu
2010-03-04 10:08 ` [PATCH 11/12] x86/iommu/dmar: update iommu/inter_remapping to use desc Yinghai Lu
2010-03-04 10:08 ` [PATCH 12/12] x86: remove arch_probe_nr_irqs Yinghai Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1003211515310.12371@ask.diku.dk \
--to=julia@diku.dk \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®