> 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
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
>> 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
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
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
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
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
>> 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
>> 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
>>> 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
>> 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
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
> 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
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
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
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
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
>> 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
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
> 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 …
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
>> 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
>> 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
26 matches
Mail list logo