> How many times have I told you to include the reason for your patches
> in your proposed commit message?
Will it be useful to look again at the involved circumstances?
> Too often.
Did I answer any concerns partly?
> Many people do not know that a generic kmalloc does a dump_stack() on OOM.
On Tue, Nov 28, 2017 at 01:13:51PM +0100, SF Markus Elfring wrote:
> Additional improvement possibilities can be taken into account
> after corresponding software development discussions, can't they?
Sure, but that is in contrary to all you replies. I guess you are
familiar with Documentation/proc
>> Additional improvement possibilities can be taken into account
>> after corresponding software development discussions, can't they?
>
> Sure, but that is in contrary to all you replies.
Where do you see a contradiction in this case?
> I guess you are familiar with Documentation/process/submi
On Tue, 2017-11-28 at 11:23 +0100, Ladislav Michl wrote:
> I do not follow. This is OMAP framebuffer driver, so in this case, there
> is zero variation. Could you, please, review following patch and verify
> is it satisfies your automated static code analysis test?
Obviously a better patch.
I sug
On Tue, Nov 28, 2017 at 11:50:14AM +0100, SF Markus Elfring wrote:
> >> How will this aspect evolve further?
> >
> > I do not follow.
>
> Interesting …
>
> > This is OMAP framebuffer driver, so in this case, there is zero variation.
>
> How much are you interested to compare differences in buil
On Tue, Nov 28, 2017 at 12:04:04AM -0800, Joe Perches wrote:
> On Tue, 2017-11-28 at 08:41 +0100, SF Markus Elfring wrote:
> > > > It seems that I got no responses so far for clarification requests
> > > > according to the documentation in a direction I hoped for.
> > >
> > > That's because you ar
On Tue, Nov 28, 2017 at 11:15:37AM +0100, SF Markus Elfring wrote:
> >>> Many people do not know that a generic kmalloc does a
> >>> dump_stack() on OOM.
> >>
> >> This is another interesting information, isn't it?
> >>
> >> It is expected that the function “devm_kzalloc” has got a similar property
>> 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 sugge
>> How will this aspect evolve further?
>
> I do not follow.
Interesting …
> This is OMAP framebuffer driver, so in this case, there is zero variation.
How much are you interested to compare differences in build results
also for this software module because of varying parameters?
Which parame
>>> Many people do not know that a generic kmalloc does a
>>> dump_stack() on OOM.
>>
>> This is another interesting information, isn't it?
>>
>> It is expected that the function “devm_kzalloc” has got a similar property.
>
>
> You don't have to expect this. Go look at the definition of devm_kza
>> I got an other impression. The probability for disagreements is increasing
>> in relation to the number of contributors to which I show change
>> possibilities.
>
> No. You should learn from the previous submissions what concerns people
> have and address them up front.
The concerns can vary
On Tue, 28 Nov 2017, SF Markus Elfring wrote:
> > How many times have I told you to include the reason for
> > your patches in your proposed commit message?
>
> It might be useful to look again.
>
>
> > Too often.
>
> I answered this feedback to some degree.
>
>
> > Many people do not know that
On Tue, 28 Nov 2017, SF Markus Elfring wrote:
> It seems that I got no responses so far for clarification requests
> according to the documentation in a direction I hoped for.
> >>>
> >>> That's because you are pretty unresponsive to direction.
> >>
> >> From which places did you get t
> How many times have I told you to include the reason for
> your patches in your proposed commit message?
It might be useful to look again.
> Too often.
I answered this feedback to some degree.
> Many people do not know that a generic kmalloc does a
> dump_stack() on OOM.
This is another in
It seems that I got no responses so far for clarification requests
according to the documentation in a direction I hoped for.
>>>
>>> That's because you are pretty unresponsive to direction.
>>
>> From which places did you get this impression?
>
> Perhaps from the text that you have writ
On Mon, Nov 27, 2017 at 08:22:51PM +0100, Ladislav Michl wrote:
> On Mon, Nov 27, 2017 at 07:12:50PM +0100, SF Markus Elfring wrote:
> > >> Can a default allocation failure report provide the information
> > >> which you might expect so far?
> > >
> > > You should be able to answer that question y
On Mon, Nov 27, 2017 at 03:33:13PM -0600, Andrew F. Davis wrote:
> On 11/27/2017 01:07 PM, Joe Perches wrote:
> > On Mon, 2017-11-27 at 10:43 -0600, Andrew F. Davis wrote:
> >> On 11/26/2017 12:55 PM, SF Markus Elfring wrote:
> >>> From: Markus Elfring
> >>> Date: Sun, 26 Nov 2017 19:46:09 +0100
>
On 11/27/2017 01:07 PM, Joe Perches wrote:
> On Mon, 2017-11-27 at 10:43 -0600, Andrew F. Davis wrote:
>> On 11/26/2017 12:55 PM, SF Markus Elfring wrote:
>>> From: Markus Elfring
>>> Date: Sun, 26 Nov 2017 19:46:09 +0100
>>>
>>> Omit an extra message for a memory allocation failure in these funct
On Mon, Nov 27, 2017 at 07:12:50PM +0100, SF Markus Elfring wrote:
> >> Can a default allocation failure report provide the information
> >> which you might expect so far?
> >
> > You should be able to answer that question yourself.
>
> I can not answer this detail completely myself because my kn
On Mon, Nov 27, 2017 at 06:27:08PM +0100, SF Markus Elfring wrote:
> >> Omit an extra message for a memory allocation failure in these functions.
> …
> > nak, unlike many others, these message give extra info on which
> > allocation failed, that can be useful.
>
> Can a default allocation failure
On Tue, 2017-11-28 at 08:41 +0100, SF Markus Elfring wrote:
> > > It seems that I got no responses so far for clarification requests
> > > according to the documentation in a direction I hoped for.
> >
> > That's because you are pretty unresponsive to direction.
>
> From which places did you get
On Tue, 28 Nov 2017, SF Markus Elfring wrote:
> >> It seems that I got no responses so far for clarification requests
> >> according to the documentation in a direction I hoped for.
> >
> > That's because you are pretty unresponsive to direction.
>
> From which places did you get this impression
>> It seems that I got no responses so far for clarification requests
>> according to the documentation in a direction I hoped for.
>
> That's because you are pretty unresponsive to direction.
From which places did you get this impression?
> You've gotten _many_ replies to your patches
I got t
On Mon, 2017-11-27 at 22:48 +0100, SF Markus Elfring wrote:
> It seems that I got no responses so far for clarification requests
> according to the documentation in a direction I hoped for.
That's because you are pretty unresponsive to
direction.
You've gotten _many_ replies to your patches to
wh
> There is the generic stack dump on OOM so the module/line
> is already known.
Can such an implementation detail become better documented
than in C source code?
> The existence of these messages increases code size which
> also make the OOM condition slightly more likely.
Interesting view …
On Mon, 2017-11-27 at 10:43 -0600, Andrew F. Davis wrote:
> On 11/26/2017 12:55 PM, SF Markus Elfring wrote:
> > From: Markus Elfring
> > Date: Sun, 26 Nov 2017 19:46:09 +0100
> >
> > Omit an extra message for a memory allocation failure in these functions.
> >
> > This issue was detected by usi
Hi Markus,
On Mon, Nov 27, 2017 at 7:12 PM, SF Markus Elfring
wrote:
>>> Can a default allocation failure report provide the information
>>> which you might expect so far?
>>
>> You should be able to answer that question yourself.
>
> I can not answer this detail completely myself because my know
>> Can a default allocation failure report provide the information
>> which you might expect so far?
>
> You should be able to answer that question yourself.
I can not answer this detail completely myself because my knowledge
is incomplete about your concrete expectations for the exception handli
On 11/26/2017 12:55 PM, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 26 Nov 2017 19:46:09 +0100
>
> Omit an extra message for a memory allocation failure in these functions.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
n
>> Omit an extra message for a memory allocation failure in these functions.
…
> nak, unlike many others, these message give extra info on which
> allocation failed, that can be useful.
Can a default allocation failure report provide the information
which you might expect so far?
Regards,
Markus
From: Markus Elfring
Date: Sun, 26 Nov 2017 19:46:09 +0100
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/video/fbdev/omap2/omapfb/dss/dispc.c| 4 +---
drivers/vi
31 matches
Mail list logo
