lkml.org 
[lkml]   [2017]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: omapfb/dss: Delete an error message for a failed memory allocation in three functions
From
Date
>> I am not going to “verify” your update suggestion by my evolving approaches
>> around the semantic patch language (Coccinelle software) at the moment.
>
> As you are sending patches as Markus Elfring

I am contributing also some update suggestions.


> I would expect you take Coccinelle's suggestion into account

The proposed change is based on a semantic patch script which I developed
with the support of other well-known Linux contributors.


> and actually try to understand code before sending patch.

I concentrated my understanding on the concrete transformation pattern
in this use case.


> That suggestion may lead to actual bug in code which your patch just leaves
> unnoticed as it is not apparent from the patch itself

There can be other change possibilities left over as usual.


> (no, not talking about this very patch it all started with)

Thanks for your distinction.


> That said, I'm considering Markus Elfring being a human.

Thanks for this view.


> If you do not like reactions to your patches

I am looking for constructive responses. - Disagreements can trigger
special communication challenges.


> or are interested only in improving tool that generates them,

How do you think about to look at any more background information?

https://github.com/coccinelle/coccinelle/issues
https://systeme.lip6.fr/pipermail/cocci/


> it would be better to just setup a "tip bot for Markus
> Elfring" and let it send patches automatically.

There is already an other automatic source code analysis system active.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/scripts/coccinelle


> The way you are sending patches makes impression (at least to me),
> that you spent some time on fixing issue Coccinelle found

Yes. - This view is appropriate.


> and not just shut the warning up.

Additional improvement possibilities can be taken into account
after corresponding software development discussions, can't they?

Regards,
Markus

\
 
 \ /
  Last update: 2017-11-28 13:14    [W:0.099 / U:0.904 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site