lkml.org 
[lkml]   [2011]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86/EFI: properly pre-initialize table pointers
>>> On 05.07.11 at 11:33, Ingo Molnar <mingo@elte.hu> wrote:

> * Jan Beulich <JBeulich@novell.com> wrote:
>
>> Consumers of the table pointers in struct efi check for
>> EFI_INVALID_TABLE_ADDR to determine validity, hence these pointers
>> should all be pre-initialized to this value (rather than zero).
>>
>> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>>
>> ---
>> arch/x86/platform/efi/efi.c | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> This changelog is missing some key information:
>
> - how did you find the bug (by chance via code review or did you see
> some actual badness?)

I can certainly add that information and re-send, but would certainly
have stated any really bad effect if I had observed such.

> - what practical effect (if any) did you see from this patch?
>
> - what practical effect (if any) do you expect others to see from this
> patch?

Hmm, I can't really see why this kind of information (especially the
last) would belong into a changeset comment, the more a pretty
obvious one like this.

> This kind of information helps us prioritize bugfixes.

Bug fixes are bug fixes - unless they fix really critical issues (and
here that's unlikely to be the case, as the code had been wrong
for ages), I don't follow why you require more information to be
added than a description of what gets changed (the "why" should
really only matter if it's debatable whether the original code was
wrong).

Furthermore, this being not the first time you ask (from my pov)
to be overly verbose when it comes to describing changes and
their effects - is it unreasonable to expect you (not always you
personally, but you as being one of the three x86 maintainers;
you hopefully agree that from my position it doesn't really
matter who answers as long as someone assumes that
responsibility) to be a little less lax in responding to submitted
patches? I would roughly estimate that 50% of the patches I
send get dropped on the floor with no response whatsoever
(there are even cases where you welcomed patches, but never
applied them or responded with a revised opinion on a re-
submission). I clearly realize that the volume you need to deal
with must be pretty high, yet I don't think that ought to be an
excuse for other than occasional cases of this happening.

And yes, there are also other times when things get integrated
*very* quickly, and I definitely appreciate that.

Jan

> Thanks,
>
> Ingo





\
 
 \ /
  Last update: 2011-07-05 13:19    [W:0.082 / U:0.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site