mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Julia Lawall <julia@diku.dk>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: Nicolas Palix <npalix@diku.dk>, Joe Perches <joe@perches.com>,
	devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org,
	yoann padioleau <yoann.padioleau@gmail.com>
Subject: Re: Typedef removal tool
Date: Wed, 12 Aug 2009 17:57:06 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0908121748160.8540@pc-004.diku.dk> (raw)
In-Reply-To: <43e72e890908120845k435e5838sf40e90dfd6869b7d@mail.gmail.com>

> BTW I was under the impression spatch wouldn't touch header files or
> dive in to untangle macros. Is that incorrect? Would the cocci files
> allow spatch to not only change typdef usages with simple struct uses
> but also redefine a typedef declaration to a simple struct definition
> through header files? For upstream work I don't expect as much macro
> mess as you would with typical vendor drivers. For drivers which do
> need to get ported I do expect an tangling web of macro mess one may
> need to put up with at times.

spatch looks at header files to a user-controllable degree: -no_includes 
means ignore all #includes, -local_includes means consider include 
files in the current directory, and -all_includes means consider all 
direct #includes.  There is no option to consider files that are included 
by included files.

If a header file is included, then spatch is willing to generate patches 
for transformations within the header file.  An inconvenience is that 
if a single header file is included multiple times, a patch will be 
generated for it each time as well.  In the worst case, these patches 
might not even be consistent.

There is also an increasing effort to take into account macro definitions, 
when they are available and useful.  I don't know the exact current status 
of that, however.  Perhaps Yoann (in CC) can explain.


In the general case, there it is not possible to write a rule to change a 
typedef to a simple structure declaration with the same name as the 
typedef.  The problem is that typedef declares something that is parsed as 
a type and the name of a struct is an identifier.  Spacth doesn't allow 
you to put a type in a position where an identifier is expected.  
Nicolas' code, however, gets around the problem by using python to 
generate new semantic patches.  In the new semantic patch, the typedef 
name is just a constant, and thus parsed as convenient for the position in 
which it appears (once as a type name and once as a struct name).


julia

      reply	other threads:[~2009-08-12 15:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-11 21:18 Luis R. Rodriguez
2009-08-12  5:01 ` Julia Lawall
2009-08-12  7:45   ` Luis R. Rodriguez
2009-08-12 12:23     ` Nicolas Palix
2009-08-12 15:45       ` Luis R. Rodriguez
2009-08-12 15:57         ` Julia Lawall [this message]

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.0908121748160.8540@pc-004.diku.dk \
    --to=julia@diku.dk \
    --cc=devel@driverdev.osuosl.org \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@gmail.com \
    --cc=npalix@diku.dk \
    --cc=yoann.padioleau@gmail.com \
    /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®