>> … >>> +++ b/scripts/coccinelle/misc/secs_to_jiffies.cocci >>> @@ -11,12 +11,22 @@ >>> >>> virtual patch >> … >>> -@depends on patch@ constant C; @@ >>> +@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@xxxxxx/ 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
