[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1905131350330.1009@hadrien>
Date: Mon, 13 May 2019 13:51:39 +0200 (CEST)
From: Julia Lawall <julia.lawall@...6.fr>
To: Markus Elfring <Markus.Elfring@....de>
cc: Gilles Muller <Gilles.Muller@...6.fr>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Michal Marek <michal.lkml@...kovi.net>,
Nicolas Palix <nicolas.palix@...g.fr>,
Wen Yang <wen.yang99@....com.cn>, cocci@...teme.lip6.fr,
linux-kernel@...r.kernel.org, Yi Wang <wang.yi59@....com.cn>
Subject: Re: [3/5] Coccinelle: put_device: Merge four SmPL when constraints
into one
On Mon, 13 May 2019, Markus Elfring wrote:
> >> An assignment target was repeated in four SmPL when constraints.
> >> Combine the exclusion specifications into disjunctions for the semantic
> >> patch language so that this target is referenced only once there.
> >
> > NACK.
>
> I find this rejection questionable.
>
>
> > This exceeds 80 characters
>
> The line became 105 characters long.
> 14 space characters can eventually be omitted.
>
>
> > and provides no readability benefit.
>
> I try to stress SmPL functionality in this use case.
That's not the goal of the semantic patches in the kernel.
The rule is fine as it is.
> >> +++ b/scripts/coccinelle/free/put_device.cocci
> >> @@ -23,10 +23,7 @@ if (id == NULL || ...) { ... return ...; }
> >> when != platform_device_put(id)
> >> when != of_dev_put(id)
> >> when != if (id) { ... put_device(&id->dev) ... }
> >> - when != e1 = (T)id
> >> - when != e1 = (T)(&id->dev)
> >> - when != e1 = get_device(&id->dev)
> >> - when != e1 = (T1)platform_get_drvdata(id)
> >> + when != e1 = \( (T) \( id \| (&id->dev) \) \| get_device(&id->dev) \| (T1)platform_get_drvdata(id) \)
>
> How do you think about to extend the Coccinelle software in the way
> that such a detailed constraint can be specified on separate lines
> (without duplicated SmPL code)?
This causes some ambiguities in the parser. No change is likely to occur
here.
julia
>
> How long will it take to reconsider corresponding software limitations?
>
> Regards,
> Markus
>
Powered by blists - more mailing lists