> Would you like to try another SmPL script variant out?
@replacement@
constant text;
expression value;
@@
.driver = {
- .name = text,
- .of_match_table = value,
- },
+ .name = text,
+ .of_match_table = of_match_ptr(value),
+ },
How do you t
> +- e1 = devm_ioremap_resource(arg4, id);
> ++ e1 = devm_platform_ioremap_resource(arg1, arg3);
Can the following specification variant matter for the shown SmPL
change approach?
+ e1 =
+- devm_ioremap_resource(arg4, id
++ devm_platform_ioremap_resource(arg1, arg3
+
>>> +- e1 = devm_ioremap_resource(arg4, id);
>>> ++ e1 = devm_platform_ioremap_resource(arg1, arg3);
>>
>> Can the following specification variant matter for the shown SmPL
>> change approach?
>>
>> + e1 =
>> +- devm_ioremap_resource(arg4, id
>> ++ devm_platform_ioremap_resource(arg1, arg3
Hello,
The Coccinelle software supports also a variant of parallel data processing
after the parameter “--jobs” was passed.
https://github.com/coccinelle/coccinelle/blob/7ec31ed1fadf738bc487ccefdc63bfe0598f44cc/docs/manual/spatch_options.tex#L745
It is nice when it works to distribute analysis on
> https://github.com/coccinelle/coccinelle/issues/50
Would you like to adjust the situation around better software collaboration?
https://docs.sqlalchemy.org/en/13/core/pooling.html#using-connection-pools-with-multiprocessing
Regards,
Markus
___
Cocci m
Am 10.06.19 um 23:00 schrieb Julia Lawall:
>
>
> On Sun, 9 Jun 2019, Markus Elfring wrote:
>
>> Hello,
>>
>> The Coccinelle software supports also a variant of parallel data processing
>> after the parameter “--jobs” was passed.
>> htt
>> The flag “IORESOURCE_MEM” is passed as the second parameter for the call
>> of the function “platform_get_resource” in this refactoring.
>
> In that particular case, we maybe should consider separate inline
> helpers instead of passing this is a parameter.
>
> Maybe it would even be more efficie
> Apparently I'm missing this obscure line in the documentation:
>
> "Fresh identifier metavariables must only be used in + code."
>
> Any suggestions on how to work around this, other than use Python?
Would you get into the mood to adjust this software situation any more?
(Increase OCaml developm
From: Markus Elfring
Date: Fri, 14 Jun 2019 11:05:33 +0200
Two function calls were combined in this function implementation.
Inline corresponding code so that extra error checks can be avoided here.
Signed-off-by: Markus Elfring
---
drivers/base/platform.c | 39
>> Two function calls were combined in this function implementation.
>> Inline corresponding code so that extra error checks can be avoided here.
>
> I don't see any point to this at all.
Would you like to take another look at corresponding design options?
How do you think about to check run time
Hello,
A patch on a topic like “staging/rtl8723bs/core/rtw_ap: Remove redundant call
to memset” caught also my software development attention.
https://lkml.org/lkml/2019/6/15/220
https://lore.kernel.org/patchwork/patch/1089416/
https://lore.kernel.org/lkml/20190616033527.GA14062@hari-Inspiron-1545
> In the second case, Coccinelle has no way of knowing that ex is a pointer,
Can the software support pointer expressions better?
> so it doesn't feel motivated to consider that ex should be compared to NULL.
Should an isomorphism specification like “not_ptr2” help here?
https://github.com/cocc
>> Should an isomorphism specification like “not_ptr2” help here?
>> https://github.com/coccinelle/coccinelle/blob/19ee1697bf152d37a78a20cefe148775bf4b0e0d/standard.iso#L157
>
> No, because Coccinelle does not know that it is a pointer.
> How should it know?
Can the software determine that the exp
> Isomorphisms happen in advance, not during the matching process.
Can the mentioned SmPL script variant work also without taking extra
software transformations by isomorphism specifications into account?
Regards,
Markus
___
Cocci mailing list
Cocci@sys
>> Can the mentioned SmPL script variant work also without taking extra
>> software transformations by isomorphism specifications into account?
>
> Well, you already know that it doesn't. So oviously the answe is that it
> cannot.
At the moment.
> If you indicate that the expression ex is a po
>> Example:
>> struct setkey_parm *psetkeyparm;
>
> As I already told you, the isomorphisms are applied before matching
> against the C code. At that time, this information is not available.
Under which circumstances will the Coccinelle software become able
to take available data type inform
>> Two function calls were combined in this function implementation.
>> Inline corresponding code so that extra error checks can be avoided here.
>
> What exactly is the purpose of this ?
I suggest to take another look at the need and relevance of involved
error checks in the discussed function co
> As I already told you, the isomorphisms are applied before matching
> against the C code. At that time, this information is not available.
Can the software situation be clarified also by omitting Coccinelle's
isomorphisms?
(Can this functionality be temporarily switched off for a specific SmPL
> If you turn off isomorphisms, it will only match exactly what you have
> written.
This setting can occasionally be appropriate.
> Isomorphisms have a cost, so the provided isomorphism only converts !X to
> X == NULL when X is a pointer. If you want to make an isomorphism that
> does somethin
>> Would you like to check the software circumstances once more
>> for the generation of a similar code structure by a C compiler
>> (or optimiser)?
>
> As said: unfortunately, I don't have the time to do that
I became curious if you would like to adjust your software development
attention a bit m
> Isomorphisms have a cost, so the provided isomorphism only converts !X to
> X == NULL when X is a pointer.
It seems that the Coccinelle software has got restrictions on
the interpretation of pointers so far.
Is a pointer recognised for application of isomorphisms by
the semantic patch language o
> How would Coccinelle know that a pointer is expected if there is no asterisk?
SmPL expression metavariables can handle also pointer variables from C code,
can't they?
Type distinctions have got other consequences for isomorphism definitions.
Regards,
Markus
> How would Coccinelle know that a pointer is expected if there is no asterisk?
I am still trying to achieve a better understanding around the interpretation
of the specification “expression *X;”.
https://github.com/coccinelle/coccinelle/blob/19ee1697bf152d37a78a20cefe148775bf4b0e0d/standard.iso#L
>> https://github.com/coccinelle/coccinelle/blob/19ee1697bf152d37a78a20cefe148775bf4b0e0d/standard.iso#L151
>>
>> It looks like that it should refer to a pointer dereference
>> (according to a view for the semantic patch language).
>> But the really desired meaning might be different for the suppor
>>> Metavariables have types. Here X has pointer type.
>>
>> Our understanding of this software detail seems to match.
>>
>> But I assume that the asterisk can be treated in a different way by
>> the isomorphism definition language in comparison to the semantic
>> patch language.
>> How much does
> You can't specify pointer dereferences by metavariables.
Thanks for another clarification for a detail by the Coccinelle software.
I assumed that this would be useful functionality for the specification
“expression *X;”.
> The pattern is only in the pattern. It is not partly in the metavaria
>> Would you like to add this information to the software documentation?
>
> Not really. The documentation can't defend against everyone's imagination.
Will it become helpful to mention the metavariable type “expression *”
also in the SmPL manual?
https://github.com/coccinelle/coccinelle/blob/cad
>> Would you like to add this information to the software documentation?
>
> Not really. The documentation can't defend against everyone's imagination.
Will it become helpful to mention the metavariable type “expression *”
also in the SmPL manual?
https://github.com/coccinelle/coccinelle/blob/cad
Hello,
A patch on a topic like “[next] lkdtm: remove redundant initialization of ret”
caught also my software development attention.
https://lkml.org/lkml/2019/6/14/265
https://lore.kernel.org/patchwork/patch/1088971/
https://lore.kernel.org/lkml/20190614094311.24024-1-colin.k...@canonical.com/
From: Markus Elfring
Date: Thu, 20 Jun 2019 19:12:53 +0200
The function “devm_ioremap_resource” contains appropriate error reporting.
Thus it can be questionable to present another error message
at other places.
Provide design options for the adjustment of affected source code
by the means of
>> +@display depends on context@
>> +expression e;
>> +@@
>> + e = devm_ioremap_resource(...);
>> + if (IS_ERR(e))
>> + {
>> +* dev_err(...);
>> +return (...);
>> + }
>
> Why do you assume that there is exactly one dev_err and one return after
> the test?
I propose to start with the addition
>> +@display depends on context@
>> +expression e;
>> +@@
>> + e = devm_ioremap_resource(...);
>> + if (IS_ERR(e))
>> + {
>> +* dev_err(...);
>> +return (...);
>> + }
>
> Why do you assume that there is exactly one dev_err and one return after
> the test?
I propose to start with the addition
>> Would you prefer to clarify a more advanced approach?
>
> I think that something like
>
> if (IS_ERR(e))
> {
> <+...
> *dev_err(...)
> ...+>
> }
>
> would be more appropriate.
This SmPL construct can be more powerful.
> Whether there is a return or not doesn't really matter.
Such an adjustme
> I think that something like
>
> if (IS_ERR(e))
> {
> <+...
> *dev_err(...)
> ...+>
> }
>
> would be more appropriate. Whether there is a return or not doesn't
> really matter.
Do you find the following SmPL change specification useful and acceptable?
@deletion depends on patch@
expression e;
> I still don't see the point of specifying return. Why not just S, where S
> is a statement metavariable?
Do you find the following SmPL change specification more appropriate?
@deletion depends on patch@
expression e;
statement s;
@@
e = devm_ioremap_resource(...);
if (IS_ERR(e))
(
-{
- dev
> I still don't see the point of specifying return. Why not just S, where S
> is a statement metavariable?
Do you find the following SmPL change specification more appropriate?
@deletion depends on patch@
expression e;
statement s;
@@
e = devm_ioremap_resource(...);
if (IS_ERR(e))
(
-{
- dev
Hello,
I became interested in another source code transformation again.
I would like to move a bit of common code to the end of a function
implementation
with the help of the following script for the semantic patch language.
@replacement@
expression info, result;
identifier target, work;
type t
Hello,
I have tried out to build the current Coccinelle software again based on
the OPAM switch “4.08.0”.
Unfortunately, I stumble on the following error message.
…
ocamlfind ocamlc -c -no-alias-deps -I . stdcompat__pervasives.ml -o
stdcompat__pervasives.cmo
File "stdcompat__pervasives.ml", li
>> elfring@Sonne:~/Projekte/Linux/next-patched> spatch
>> ~/Projekte/Coccinelle/janitor/show_questionable_variable_initialisation1.cocci
>> drivers/misc/lkdtm/core.c
>> …
>> exn while in timeout_function
>> Fatal error: exception Coccinelle_modules.Common.Impossible(56)
>>
>>
>> How do you think
> It could be helpful to replace the last line by:
>
> (
> e3 = <+...var...+>
Can this SmPL specification make sense as another when constraint?
> |
> * var = e3
> )
>
> In that case, it would also be beneficial to remove the *
I find the asterisk required here
> on the variable declaration
>>> In that case, it would also be beneficial to remove the *
>>
>> I find the asterisk required here
>
> Yu can do whatever you want, but you will get lotsof false positives if
> you keep it. If you really want a star on the declaration
I would prefer to use a minus character for the specificati
>>> It could be helpful to replace the last line by:
>>>
>>> (
>>> e3 = <+...var...+>
>>
>> Can this SmPL specification make sense as another when constraint?
>
> No.
I imagine that a few extensions like the following can become safer.
when != do ds while( \( var bo e3 \| var \) );
wh
> Yu can do whatever you want, but you will get lotsof false positives if
> you keep it. If you really want a star on the declaration then you need
> to make two rules. The first that finds the positions of the places that
> match and the second that only puts a * when there is both a matched
> d
> Yu can do whatever you want, but you will get lotsof false positives if
> you keep it. If you really want a star on the declaration then you need
> to make two rules. The first that finds the positions of the places that
> match and the second that only puts a * when there is both a matched
> d
> Try
>
> ... when any
>
> just before the final ). In some circumstaces the parser doesn't accept
> an expression at the end of a sequence like you have here.
Thanks for your quick response.
The addition of such a SmPL ellipsis helps somehow.
But I am still not pleased with the generated transf
> Try
>
> ... when any
>
> just before the final ). In some circumstaces the parser doesn't accept
> an expression at the end of a sequence like you have here.
Thanks for your quick response.
The addition of such a SmPL ellipsis helps somehow.
But I am still not pleased with the generated transf
Am 23.06.19 um 15:13 schrieb Julia Lawall:
>
>
> On Sun, 23 Jun 2019, Markus Elfring wrote:
>
>>> Try
>>>
>>> ... when any
>>>
>>> just before the final ). In some circumstaces the parser doesn't accept
>>> an expression a
Hello,
The semantic patch language supports metavariables.
It can occur then that a source code search should be performed for items
which should be different while they belong still to the same data type.
(If these items would be identical, the software situation would provide
opportunities to si
> The expected difference can trigger the need to express this detail
> by the usage of two identifiers based on the same metavariable type.
I guess that this wording should be clarified a bit more according to
the current software development status around the semantic patch language.
A selection
> @@
> expression x;
> constant c1,c2;
> @@
>
> x = c1;
> (
> x = c1;
> |
> *x = c2;
> )
Thanks for your suggestion of the possible usage of a SmPL disjunction.
* Does it indicate a search attempt to match the first assignment statement
twice
(for the implementation of exclusion of duplicate s
> @@
> expression x;
> constant c1,c2;
> @@
>
> x = c1;
The SmPL manual contains the promising wording “As metavariables are bound
and inherited across rules, …”.
https://github.com/coccinelle/coccinelle/blob/c6d7554edf7c4654aeae4d33c3f040e300682f23/docs/manual/cocci_syntax.tex#L179
The mentioned
> * The complete source file seems to be very challenging for testing
> the run time characteristics.
How are the chances to clarify the different test results for this source code
transformation approach with the software combination “Coccinelle
1.0.7-00211-geaa13d59-dirty
(OCaml 4.07.1)”?
el
> Maybe there are too many metavariable bindings.
Under which circumstances would such a situation really occur?
How do you think about my SmPL script example for the shown use case?
> You can try with the option --debug.
> Or if that doesn't help with the option --verbose-ctl-engine.
How can
>>> You can try with the option --debug.
>>> Or if that doesn't help with the option --verbose-ctl-engine.
>>
>> How can these parameters help to clarify undesirable run time
>> characteristics?
>
> How about actually looking at the results yourself?
I did that. - I do not find these extra data s
>> replacement: already tagged token:
>
> You try to add two things one one token, which is not allowed.
How do you think about to clarify why a source file adjustment
like the following can let my SmPL script succeed in a test configuration?
elfring@Sonne:~/Projekte/Coccinelle/Probe> diff -u meg
>> Where did the Coccinelle software get the impression that anything
>> would be added too often at the end of such a function implementation?
>
> Without the semantic patch and the C source code,
You have access to data from both files already.
> I can't answer the question.
Is it more conven
> The counter must be decremented after the last usage of a device node.
Thanks for your next try to improve the software situation
also in this area.
> We find these functions by using the following SmPL:
Would it be nicer to use the word “script” also here?
>
> @initialize:ocaml@
> @@
How
>> +x =
>> +(of_…
>> +|of_…
>> +)@p1(...);
>
> Did you actually test this? I doubt that a position metavariable can be
> put on a ) of a disjunction.
Would you ever like to support this possibility?
>> +|return
>> +(x
>> +|of_fwnode_handle(x)
>> +);
>
> The original code is much more readable.
>> +x =
>> +(of_…
>> +|of_…
>> +)@p1(...);
>
> Did you actually test this? I doubt that a position metavariable can be
> put on a ) of a disjunction.
Would you ever like to support this possibility?
>> +|return
>> +(x
>> +|of_fwnode_handle(x)
>> +);
>
> The original code is much more readable.
>> +if (x == NULL || ...) S
>> +... when != e = (T)x
>> +when != true x == NULL
>
> I wonder if this code exclusion specification is really required
> after a null pointer was checked before.
I would like to add another view for this implementation detail.
The when constraint can express a so
+if (x == NULL || ...) S
+... when != e = (T)x
+when != true x == NULL
…
> I assume that it was added because it was found to be useful.
We can get different software development opinions also on
this implementation detail.
> Please actually try things out before declaring the
> Please actually try things out before declaring them to be useless.
This feedback provides also another opportunity for collateral evolution
in some directions. I am curious on how involved uncertainty can be fixed around
possibly different interpretation for provided software functionality.
Th
From: Markus Elfring
Date: Mon, 1 Jul 2019 10:00:39 +0200
The function “devm_ioremap_resource” contains appropriate error reporting.
Thus it can be questionable to present another error message
at other places.
Provide design options for the adjustment of affected source code
by the means of
> By the way: do we have any mechanism for explicitly suppressing
> individual warnings (some kind of annotation),
I do not know such an accepted specification interface
(for the handling together with SmPL scripts) so far.
How would you identify possibly unwanted messages in a safe way?
> when
> We will also provide an example written in Python later.
Will the code move from the commit description into a file
for your next patch version?
> We first use this script to find out all the function names to be processed,
I am still curious on how the output format selection will become cle
> We tested and found that both <...x...> and <+... x ...+> variants work fine.
Is the difference in the functionality from this SmPL construct clear already?
> We use <... x ...> instead of <+... x ...+> here to eliminate the following
> false positives:
Do we stumble on another software desi
Hello,
The semantic patch language supports also to convert conditional statements
into usages of the ternary operator.
How much can the Coccinelle software help with pretty-printing of generated
source code in this area?
Would you like to achieve any improvements for automatic code beautification
>> Would you like to achieve any improvements for automatic code beautification?
>> https://github.com/coccinelle/coccinelle/issues/37
>
> If you want to report a problem,
I became curious again if more contributors would become interested
to influence a possibly known software situation a bit mor
>> elfring@Sonne:~/Projekte/Coccinelle/Probe> spatch
>> ../janitor/use_call_with_ternary_operator1.cocci ksm-excerpt1.c
>> …
>> +list_add_tail(&mm_slot->mm_list,
>> + (ksm_run & KSM_RUN_UNMERGE) ? &ksm_mm_head.mm_list :
>> &ksm_scan.mm_slot->mm_list);
>
> And this is unsatisf
>> @script:python depends on report && r1@
>
> No need to depend on r1. That is guaranteed by the inheritance on the
> metavariables below.
Will this information become more helpful for the completion of the
corresponding
software documentation?
Regards,
Markus
>> I will apply with Julia's Signed-off-by instead of Acked-by.
>> I will also add SPDX tag.
>>
>> Is this OK?
>
> Yes, thanks.
Will the clarification for following implementation details get any more
software development attention?
https://systeme.lip6.fr/pipermail/cocci/2019-June/005975.ht
>>> How do you think about to increase the matching granularity
>>> for this functionality?
>>
>> No idea what this means. Disjunctions are expanded up to the level of the
>> nodes in the control-flow graph.
>
> We have got different expectations for working with such nodes
> for possible (data fl
> 110: ierr_out:
> 111: of_node_put(trng); ---> double released here
> ...
>
> This issue was detected by using the Coccinelle software.
Such a detection of a questionable source code place can be nice and helpful.
I constructed another script variant for the semantic patch languag
> But I wonder at the moment why it does not work (as expected) for the original
> complete source file.
I discovered that a diff hunk (or usable patch?) is generated
if the return statement is deleted (or commented out) before the jump label
which refers to a potentially unwanted function call at
> Has anyone attempted to port coccinelle to OCaml 4.08?
I am unsure also about this detail.
> It seems
to require multiple complex changes.
I am waiting on corresponding software improvements according to a report
like “Checking dependencies for current OCaml compiler version”.
https://system
> we recently have lots of patches for either adding missing NULL checks,
> removing unneeded ones, etc.
Would you like to point any more concrete change examples out?
> It seems that's an non-trivial terrain,
This area can be also challenging.
> so I'm thinking about potential compiler sup
My software development attention was caught also by your proposal.
I would appreciate a message subject without a typo.
> +virtual patch
> +virtual context
> +virtual org
> +virtual report
These metavariables are not used in the subsequent code in this approach
for the semantic patch language.
> We find these functions by using the following script:
Why would you like to keep this SmPL code in the commit description?
I would prefer software evolution in an other direction.
https://lore.kernel.org/lkml/44be5924-26ca-5106-aa25-3cbc3343a...@web.de/
https://lkml.org/lkml/2019/7/4/21
> @i
>> Why would you like to keep this SmPL code in the commit description?
>
> I don't know indetail what you are proposing,
I imagine that you can get more interesting software development ideas
from links to previous messages.
I hope that the desired clarification can become more constructive.
How
>> Why would you like to keep this SmPL code in the commit description?
>
> I don't know indetail what you are proposing,
I imagine that you can get more interesting software development ideas
from links to previous messages.
I hope that the desired clarification can become more constructive.
How
> 2), Then SmPL A generates another SmPL B based on the function name list;
This would be a general data processing possibility.
Another option would be to let SmPL scripts to import relevant data
from external files or to query facts from databases.
> You expect the entire process above to be a
> Finally, this patch finds use-after-free issues for a node.
> (implemented by the r_use_after_put rule)
I suggest to take another look also at information from a clarification attempt
on a topic like “Checking statement order for patch generation with SmPL
support”.
https://systeme.lip6.fr/pipe
> Finally, this patch finds use-after-free issues for a node.
> (implemented by the r_use_after_put rule)
I suggest to take another look also at information from a clarification attempt
on a topic like “Checking statement order for patch generation with SmPL
support”.
https://systeme.lip6.fr/pipe
> We are looking into
using Coccinelle for refactoring in Go
Thanks for your interest.
> Does Coccinelle include support for Go?
Not yet.
> * Is there any plan to add support for the same?
Would you like to contribute significant development resources for
corresponding software extensions?
> But I also write tools that
use the Go AST package to rewrite Go,
Would you like to share any more experiences around related software?
> and have never felt the lack of
coccinelle for Go.
I find this impression interesting.
How much did you get used to functionality which is supported by
t
I would prefer to concentrate the usage of SmPL disjunctions on changing
implementation details so that the specification of duplicate code
can be avoided.
> +(
> +platform_get_irq(E, ...)
> +|
> +platform_get_irq_byname(E, ...)
> +);
Function names:
+(platform_get_irq
+|platform_get_irq_byname
> > > struct platform_device *E;
How much does this specification matter for the parameters
of the mentioned functions (in the SmPL script)?
Will the selection of function names be sufficient for the discussed
source code search pattern?
> > Can you teach it to remove curly braces when it's appr
> +@script:python depends on org@
> +p1 << r.p1;
> +@@
> +
> +cocci.print_main(p1)
Will an additional message be helpful at this place?
Will further software development considerations become more interesting
also around a contribution like “Coccinelle: Add a SmPL script for
the reconsideration
>>> +if (ret != -EPROBE_DEFER)
>>
>> Is it appropriate to treat this error code check as optional
>> by the shown transformation approach?
>> Can this case distinction be omitted?
>
> I don't know what you mean here.
I suggest to take another look at the importance and relevance
of this specific s
>> Will further software development considerations become more interesting
>> also around a contribution like “Coccinelle: Add a SmPL script for
>> the reconsideration of redundant dev_err() calls”?
>> https://lore.kernel.org/lkml/2744a3fc-9e67-8113-1dd9-43669e063...@web.de/
>> https://lore.kernel
> New version. I check for non-use of the return value of strlcpy and
> address some issues that affected the matching of the case where the first
> argument involves a pointer dereference.
I suggest to take another look at corresponding implementation details
of the shown SmPL script.
> \(strs
>>> @@
>>> (
>>> -x = strlcpy
>>> +stracpy
>>> (e1.f, e2
>>> -, i2
>>> )@p;
>>> ... when != x
>>>
>>> |
>>
>> I wonder about the deletion of the assignment target.
>> Should the setting of such a variable be usually preserved?
>
> If it is a local variable and never subsequently used, it
> @r@
> identifier f,i1,i2;
> struct i1 e1;
> expression e2;
> position p;
> @@
> \(strscpy\|strlcpy\)(e1.f, e2, i2)@p
I have got the impression that the replacement can work also
without an inherited position variable at the end.
How do you think about to omit this SmPL rule then?
Can it be nice
> Huh? Rule 2 is important, to ensure that ths size is correct.
I assume that the dependency of the replacement on the data structure check
can become clearer.
Regards,
Markus
> The rule now properly checks that the third argument is the size of the
> first argument. This made a small reduction in the number of results.
Thanks for your SmPL script adjustments.
Will deviations from this restriction become more interesting?
> \(strscpy\|strlcpy\)(e1.f, e2, i2)@p
Would
> I'm not sure this will be accepted or not
The patch review and corresponding clarification will become more interesting,
won't it?
I am missing more constructive feedback to remaining software development
concerns.
https://lore.kernel.org/patchwork/comment/1301194/
https://lore.kernel.org/lkml
> This is a note to let you know that I've just added the patch titled
>
> coccinelle: Add script to check for platform_get_irq() excessive
>
> to my driver-core git tree which can be found at
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> in the driver-core-next b
> This is a resend of patch 2/3 from the v5[1] series, but split
> up to be per-subsystem. Please apply patches directly to
> subsystem trees if possible.
>
> [1] https://lkml.kernel.org/r/20190730053845.126834-1-swb...@chromium.org
Would it have been nicer to fix also the commit descriptions befo
> I have a question regarding the new "comments" feature.
I hope that further collateral evolution will happen around this functionality.
> @ r @
> identifier fn;
> comments c;
> @@
> fn()@c
> {
> }
* Which comments will appear between a closing parenthesis and an opening curly
bracket?
> if match:
> coccinelle.km = match.group(1)
I suggest to add a bit of code like the following.
else:
cocci.include_match(False)
How do you think about to use an other SmPL rule variant?
@addition@
expression context;
identifier find_kmap_tagged_function.fn, parse_kmap
201 - 300 of 1817 matches
Mail list logo
