All of lore.kernel.org
 help / color / mirror / Atom feed
From: elfring@users.sourceforge.net (SF Markus Elfring)
To: cocci@systeme.lip6.fr
Subject: [Cocci] semantic patch feasibility
Date: Sat, 26 Apr 2014 10:30:43 +0200	[thread overview]
Message-ID: <535B6EB3.9070705@users.sourceforge.net> (raw)
In-Reply-To: <CABxcv=mEHrg0=VSRYAtMJq_papbLYQa4Y1y8j+38n7-3=V6SsQ@mail.gmail.com>

> Besides moving the function pointers assigned to the structure
> gpio_chip fields to the new struct gpio_chip_ops, a pointer to the new
> struct gpio_chip_ops has to be assigned to the struct gpio_chip .ops field.

Will any macros become relevant for such a source code reorganisation?


> So where to put the new structure is constrained by where struct
> gpio_chip fields are set. If is easier we can define to be just before
> the function where the assignments were made but I don't know if it
> can be generalized.

I am curious how a generalisation should be described here.


> But I don't want to waste your time since I still didn't have time to
> get familiar with cocinelle/spatch syntax to get into the details.

I find that the understanding of this syntax is a secondary issue. Is it more
important to clarify the basic change process before?

Do you need to consider any variations for the initialisation of the affected
data structure?
Is the specification precise enough so that such an algorithm can be added to a
kind of pattern collection?
http://refactoring.com/catalog/extractInterface.html
http://c2.com/cgi/wiki?ExtractInterface

Regards,
Markus

  parent reply	other threads:[~2014-04-26  8:30 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-25 12:32 [Cocci] semantic patch feasibility Javier Martinez Canillas
2014-04-25 14:30 ` SF Markus Elfring
2014-04-25 16:24   ` Julia Lawall
2014-04-25 16:31     ` SF Markus Elfring
2014-04-25 18:03       ` Julia Lawall
2014-04-25 18:50         ` Javier Martinez Canillas
2014-04-25 21:28           ` Julia Lawall
2014-04-25 22:02             ` Javier Martinez Canillas
2014-04-25 18:39     ` Javier Martinez Canillas
2014-04-25 18:33   ` Javier Martinez Canillas
2014-04-25 20:52     ` SF Markus Elfring
2014-04-25 21:30       ` Julia Lawall
2014-04-25 21:31     ` Julia Lawall
2014-04-25 16:23 ` Julia Lawall
2014-04-25 18:37   ` Javier Martinez Canillas
2014-04-25 21:25     ` Julia Lawall
2014-04-25 21:58       ` Javier Martinez Canillas
2014-04-26  5:11         ` Julia Lawall
2014-04-26  8:30         ` SF Markus Elfring [this message]
2014-04-26 14:06           ` Javier Martinez Canillas
2014-04-26 15:52             ` [Cocci] Extract an interface with SmPL SF Markus Elfring
2014-04-26 16:06               ` Julia Lawall
2014-04-26 16:31                 ` Javier Martinez Canillas
2014-04-26 10:59     ` [Cocci] semantic patch feasibility Julia Lawall
2014-04-25 16:34 ` Wolfram Sang

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=535B6EB3.9070705@users.sourceforge.net \
    --to=elfring@users.sourceforge.net \
    --cc=cocci@systeme.lip6.fr \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.