On Wed, 20 Apr 2016, Kieran Bingham wrote:

> Hi all,
>
> I am finding that a rule which matches a part of code, sometimes causes
> hunks which depend on it to act, and sometimes not to act
>
> My spatch is successfully removing and converting hunks that I desire
> changed, however the requirement became apparent *to not process the
> file at all* if the variable is used in the probe function, so I added
> in a dependency on probe_id_unused (established in my previous mail thread).

I'll check on the rest shortly, but if you really want to not process the
file at all, just look for the condition in which that is the case, and
then write a python rule that depends on it, and run Cocci.exit() (not
sure about the exact syntax - writing an ocaml rule and putting
Coccilib.exit() will also work).

julia

> Therefore, I would expect to be able to set the 'depends on' to be on
> 'probe_id_unused' for each of the actions, and have actions only taken
> if the full dependency chain (C4->C1 below) is met.
>
> However, I get a non-consistent application of this, where some hunks
> operate when (I believe) they shouldn't:
>
> My full spatch for reference, is at:
>
> https://gist.github.com/kbingham/96477177dd20a72b1c2f
>
> In essence, it does the following {C}hecks:
> C1 - of_dev_id_present : Check for a struct of_device_id
> C2 - dev_id : Check for a struct i2c_device_id
> C3 - driver : Check and identify the probefunc in the driver structure
> C4 - probe_id_unused : Establish if the id is used in the probe function
>
> Where C4 depends on C3 depends on C2 depends on C1
>
> The aim is that if all of the above checks/identifiers are met, it will
> take the following actions:
> A rewrite the probe function declaration
> B re-point the function pointer in the driver structure
> C remove the i2c_device_id reference
> D remove the i2c_device_id array
> E remove the MODULE_DEVICE_TABLE macro
>
> For this example, I'll take three files from the kernel source, all of
> which meet conditions C1 - > C3 (but only F3 meets C4):
>
> F1: drivers/gpio/gpio-pca953x.c  : probe id used ( ! C4 )
> F2: drivers/staging/iio/light/isl29018.c : probe id used ( ! C4 )
> F3: sound/soc/codecs/wm8737.c : probe id UNUSED ( C4 )
>
> If all the actions (A->E) start with @ depends on driver @ (to depend on
> C3) all the actions complete on these files. (Shown in sequence in the c
> file)
>
> F1 : D E A B C
> F2 : A D E B C
> F3 : A D E B C
>
> However, if all the actions depend on @ depends on probe_id_unused @
> (depends on C4), Some actions complete, and some do not!
>
> F1 : D E C       (Unexpected behaviour - I expect F1 : <no change>)
> F2 : D E C       (Unexpected behaviour - I expect F2 : <no change>)
> F3 : A D E B C   (Expected behaviour)
>
> So of course, I want actions D E and C to *not* complete on F1 and F2,
> but I can't understand why they do not comply with their 'depends'
> chain. Am I looking at a bug in Coccinelle here or a bug with my
> interpretation of the depends keyword?
>
> Sorry for the long mail, and look forward to any ideas!
>
> --
> Regards
>
> Kieran
> _______________________________________________
> Cocci mailing list
> [email protected]
> https://systeme.lip6.fr/mailman/listinfo/cocci
>
_______________________________________________
Cocci mailing list
[email protected]
https://systeme.lip6.fr/mailman/listinfo/cocci

Reply via email to