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
prev parent 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®