From: Julia Lawall <julia.lawall@lip6.fr>
To: "Luis R. Rodriguez" <mcgrof@suse.com>
Cc: cocci@systeme.lip6.fr, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [Cocci] SmPL for automatic request_firmware_nowait() conversion
Date: Sat, 21 Jun 2014 08:37:01 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.02.1406210832510.2074@localhost6.localdomain6> (raw)
In-Reply-To: <20140621015714.GX4841@wotan.suse.de>
On Sat, 21 Jun 2014, Luis R. Rodriguez wrote:
> I was just porting over an ethernet driver [0] to use request_firmware_nowait()
> since firmware loading seems can take over a minute on one device, while
> at it I noticed no other ethernet drivers yet use this API so figure
> this may be a trend coming if devices are getting as complex as cxgb4.
> The cxgb4 driver happens to even use the firmware API 3 times!
>
> Obviously I considered writing SmPL for this, but one thing which seemed
> hard was that for after the request_firmware_nowait() we tend to tuck
> away into another new call the rest of the code that was in place in the
> original function after the old request_firmware() call. Is there a way
> to dump all that code into the new routine? I think the hardest thing
> would be to also move the right set of variables over. In the third
> patch in this series for example [1] there was a state variable that
> I moved from beign static over to the ethernet private data structure.
> Its hard for me to think of how I can hint to Coccinelle enough information
> about what stuff it needs to move around. I think one hint would be:
>
> "Hey all that code that is static and is used *before* and *after* request_firmware()
> stuff it into the private data structure"
>
> We'd have to infer the private data structure but that's easy and I already know
> that's possible. Is this possible? The only other challenge I thought
> might be tough would be to come up with are rasonable call for the
> completion call, but I guess we can use the original routine name
> where request_firmware() was being used and postfix _completion or something.
This kind of thing is possible, but complicated. Basically you have to
put { } around what you want to move, then match a statement metavariable
against the code that is now surrounded by braces, then find all of the
variables that are read without being initialized in the { } region, or
that are written by the { } region and used afterwards and arrange to copy
them back and forth. I did this in the context of a project where the
goal was to move critical sections into separate functions, but it was
around 1000 lines of SmPL code.
If one were doing this in several places onesself, then it would probably
be better to do the fixed parts using SmPL and do the more variable parts
by hand. This is not really something that one would want to publoish for
others, though.
julia
next prev parent reply other threads:[~2014-06-21 6:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-21 1:57 Luis R. Rodriguez
2014-06-21 6:37 ` Julia Lawall [this message]
2014-06-21 6:50 ` [Cocci] " SF Markus Elfring
2014-06-21 10:52 ` Francois Romieu
2014-06-23 23:21 ` Luis R. Rodriguez
2014-06-24 0:32 ` [Cocci] " Luis R. Rodriguez
2014-06-24 21:58 ` Francois Romieu
2014-06-24 22:06 ` Luis R. Rodriguez
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=alpine.DEB.2.02.1406210832510.2074@localhost6.localdomain6 \
--to=julia.lawall@lip6.fr \
--cc=cocci@systeme.lip6.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@suse.com \
--cc=netdev@vger.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®