On Wed, Oct 18, 2017 at 07:48:06PM +0200, SF Markus Elfring wrote:
> > For 1/4 and 2/4: explain why the message can be omitted.
>
> Why did you not reply directly with this request for the update steps
> with the subject “Delete an error message for a failed memory allocation
> in tpm_…()”?
>
> h
On Wed, 18 Oct 2017 21:03:13 +0300
Andy Shevchenko wrote:
> On Wed, 2017-10-18 at 19:48 +0200, SF Markus Elfring wrote:
> > > For 1/4 and 2/4: explain why the message can be omitted.
>
> > > That's all.
> >
> > I assume that there might be also some communication challenges
> > involved.
>
On Wed Oct 18 17, SF Markus Elfring wrote:
For 1/4 and 2/4: explain why the message can be omitted.
Why did you not reply directly with this request for the update steps
with the subject “Delete an error message for a failed memory allocation
in tpm_…()”?
https://patchwork.kernel.org/patch/100
On Wed, 2017-10-18 at 19:48 +0200, SF Markus Elfring wrote:
> > For 1/4 and 2/4: explain why the message can be omitted.
> > That's all.
>
> I assume that there might be also some communication challenges
> involved.
>
>
> > 3/4: definitive NAK, too much noise compared to value.
>
> I tried to
> One more word of advice: send the three as separate patches.
I do not see a need for an immediate resend at the moment.
> My guess is that it takes a factor longer time to apply 4/4
> than other patches because there's more limited crowd who can test it.
This is fine for me if somebody would
> For 1/4 and 2/4: explain why the message can be omitted.
Why did you not reply directly with this request for the update steps
with the subject “Delete an error message for a failed memory allocation
in tpm_…()”?
https://patchwork.kernel.org/patch/10009405/
https://patchwork.kernel.org/patch/10
On Wed, Oct 18, 2017 at 08:18:58PM +0300, Jarkko Sakkinen wrote:
> On Wed, Oct 18, 2017 at 06:43:10PM +0200, SF Markus Elfring wrote:
> > > Commit message should just describe in plain text what you are doing
> >
> > Did other contributors find the wording “Replace …”
> >
> >
> > > and why.
> >
On Wed, Oct 18, 2017 at 06:43:10PM +0200, SF Markus Elfring wrote:
> > Commit message should just describe in plain text what you are doing
>
> Did other contributors find the wording “Replace …”
>
>
> > and why.
>
> and “… a bit safer according to the Linux coding style convention.”
> sufficie
> Commit message should just describe in plain text what you are doing
Did other contributors find the wording “Replace …”
> and why.
and “… a bit safer according to the Linux coding style convention.”
sufficient often enough already?
Which description would you find more appropriate for this
On Wed, Oct 18, 2017 at 05:22:19PM +0200, SF Markus Elfring wrote:
> >> Do you find my wording “This issue was detected by using the
> >> Coccinelle software.” insufficient?
> >
> > This is fine for cover letter, not for the commits.
>
> I guess that there are more opinions available by other con
>> Do you find my wording “This issue was detected by using the
>> Coccinelle software.” insufficient?
>
> This is fine for cover letter, not for the commits.
I guess that there are more opinions available by other contributors
for this aspect.
> After your analysis software finds an issue you
On Tue, Oct 17, 2017 at 08:41:04PM +0200, SF Markus Elfring wrote:
> Do you find my wording “This issue was detected by using the
> Coccinelle software.” insufficient?
This is fine for cover letter, not for the commits.
After your analysis software finds an issue you should manually analyze
what
>> I imagine that a corresponding source code analysis variant could be applied
>> in more cases if sufficient acceptance could be achieved.
>
> So, then instead of still keeping people busy with this noise you better
> start doing something like CI integration with that for *new* code?
There are
>> Do you find my wording “This issue was detected by using the
>> Coccinelle software.” insufficient?
>
> The question is not whether it is insufficient, but whether it is appropriate.
I am curious on how our corresponding discussion will evolve further.
> Detecting Coccinelle issues is one st
On Tue, 2017-10-17 at 20:41 +0200, SF Markus Elfring wrote:
> > > p = kmalloc(sizeof(*p), ...);
> > >
> > > The alternative form where struct name is spelled out hurts
> > > readability and
> > > introduces an opportunity for a bug when the pointer variable type
> > > is changed
> > > but the co
On Tue, 2017-10-17 at 20:41 +0200, SF Markus Elfring wrote:
> Do you find my wording “This issue was detected by using the
> Coccinelle software.” insufficient?
The question is not whether it is insufficient, but whether it is
appropriate. Detecting Coccinelle issues is one step. The next step
>> p = kmalloc(sizeof(*p), ...);
>>
>> The alternative form where struct name is spelled out hurts readability and
>> introduces an opportunity for a bug when the pointer variable type is changed
>> but the corresponding sizeof that is passed to a memory allocator is not.
>
> True, thanks for
17 matches
Mail list logo
