[01/16] coccinelle: misc: secs_to_jiffies: Patch expressions too

Markus Elfring Markus.Elfring at web.de
Wed Jan 29 09:40:18 UTC 2025


>>>>> +++ b/scripts/coccinelle/misc/secs_to_jiffies.cocci
>>> @@ -11,12 +11,22 @@
>>>
>>>  virtual patch
>>>>> - at depends on patch@ constant C; @@
>>> + at depends on patch@
>>> +expression E;
>>> +@@
>>>
>>> -- msecs_to_jiffies(C * MSEC_PER_SEC)
>>> -+ secs_to_jiffies(C)
>>> +-msecs_to_jiffies
>>> ++secs_to_jiffies
>>> + (E
>>> +- * \( 1000 \| MSEC_PER_SEC \)
>>> + )
>>
>> 1. I do not see a need to keep an SmPL rule for the handling of constants
>>    (or literals) after the suggested extension for expressions.
>
> Can you explain why? Would the expression rule also address the cases
> where it's a constant or literal?

Probably, yes.


>> 2. I find it nice that you indicate an attempt to make the shown SmPL code
>>    a bit more succinct.
>>    Unfortunately, further constraints should be taken better into account
>>    for the current handling of isomorphisms (and corresponding SmPL disjunctions).
>>    Thus I would find an SmPL rule (like the following) more appropriate.
>>
>
> Sorry, I couldn't follow your sentence construction or reasoning here.
> I don't see how my patch is deficient, or different from your suggestion
> below, especially given that it follows your feedback from part 1:
> https://lore.kernel.org/all/9088f9a2-c4ab-4098-a255-25120df5c497@web.de/

I tend also to present possibilities for succinct SmPL code.
Unfortunately, software dependencies can trigger corresponding target conflicts.


> Can you point out specifically what SmPL isomorphisms or disjunctions
> are broken with the patch in its current state?

Please take another look at related information sources.
Would you like to achieve any benefits from commutativity (for multiplications)?
https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/bd08cad3f802229dc629a13eefef2018c620e905/standard.iso#L241
https://github.com/coccinelle/coccinelle/blob/cca22217d1b4316224e80a18d0b08dd351234497/standard.iso#L241


Regards,
Markus



More information about the dri-devel mailing list