On Mon, Nov 07, 2016 at 01:14:12PM +0100, Julia Lawall wrote:
>
>
> On Mon, 7 Nov 2016, Nicholas Mc Guire wrote:
>
> >
> > Hi !
> >
> > On LKML Philippe Reynes posted an API update for ethtools API for
> > the pcnet32 care, basically to replace deprecated {get|set}_settings
> > by the new API calls {get|set}_link_ksettings.
> > see: http://lkml.org/lkml/2016/11/6/2
> >
> > So the scanner for this is simple:
> >
> > <snip>
> > @find exists@
> > identifier oldapi,cmd,dev;
> > position p;
> > expression E;
> > @@
> >
> > *static int oldapi@p(struct net_device *dev, struct ethtool_cmd *cmd)
> > {
> > <+...
> > *mii_ethtool_gset(&E, cmd);
> > ...+>
> > }
> >
> > @script:python@
> > p << find.p;
> > @@
> >
> > msg = "old ethtool API in use."
> > coccilib.report.print_report(p[0], msg)
> > <snip>
> >
> > The problem was in the API update - as the get and set basically have the
> > same prototype so the find function seems to trigger in both - the
> > "solution" is a bit brute force regex in the "mod" rule - which I
> > basicall think should not be needed.
>
> I'm not completely following this... Would it work to start with the
> ethtool_ops structure? Then you could see what entry point functions need
The problem with that was that one can not tell from the ops if its
the old API or the new API - so I thought it is simpler to scan
for the old api prototypes and use the *gset/*sset functions as
check.
> to be updated? It would be good to also have a rule afterwards that looks
> for other calls to mii_ethtool_gset and mii_ethtool_sset to be sure that
> you haven't missed anything. Is the issue is that you don't want to
> modify some call to eg mii_ethtool_gset that may be in the definition of
> mii_ethtool_get_link_ksettings itself? In that case, you can do soemthing
> like the following:
>
> @exists@
> identifier f != {function_to_ignore};
> @@
>
> f(...) {
> <+...
> *function_to_warn_about(...)
> ...+> }
>
> Another approach that would be more efficient is to use the new ability to
> attach scripts to metavariables. This is illustrated in
> tests/python_poscon.cocci.
>
> @@
> position p : script:python() { p[0].current_element != "function_to_ignore" };
> @@
>
> function_to_warn_about@p(...)
>
> Let me know if I've missed understanding the issue completely.
>
nop - I´ve just managed to ignore the available capabiliteis
and come up with a complicated (and as you point out possibly
incomplete) solution. Notably the positional scripts sounds
like a simple way to resolve this in a cleaner way.
will try to unrole it from the ops side.
thx!
hofrat
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
