lkml.org 
[lkml]   [2015]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2 2/3] efi: Change abbreviation of EFI_MEMORY_RUNTIME from "RUN" to "RT"
From
On 9 September 2015 at 15:27, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Thu, 27 Aug, at 02:11:29AM, Taku Izumi wrote:
>> Now efi_md_typeattr_format() outputs "RUN" if passed EFI memory
>> descriptor has EFI_MEMORY_RUNTIME attribute. But "RT" is preferer
>> because it is shorter and clearer.
>>
>> This patch changes abbreviation of EFI_MEMORY_RUNTIME from "RUN"
>> to "RT".
>>
>> Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
>> ---
>> drivers/firmware/efi/efi.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
>> index 8124078..25b6477 100644
>> --- a/drivers/firmware/efi/efi.c
>> +++ b/drivers/firmware/efi/efi.c
>> @@ -594,8 +594,8 @@ char * __init efi_md_typeattr_format(char *buf, size_t size,
>> snprintf(pos, size, "|attr=0x%016llx]",
>> (unsigned long long)attr);
>> else
>> - snprintf(pos, size, "|%3s|%2s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
>> - attr & EFI_MEMORY_RUNTIME ? "RUN" : "",
>> + snprintf(pos, size, "|%2s|%2s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
>> + attr & EFI_MEMORY_RUNTIME ? "RT" : "",
>> attr & EFI_MEMORY_MORE_RELIABLE ? "MR" : "",
>> attr & EFI_MEMORY_XP ? "XP" : "",
>> attr & EFI_MEMORY_RP ? "RP" : "",
>
> I know that Ard suggested this change but I don't think I should apply
> this and the reason is that developers, particularly distro
> developers, come to rely on the output we print for debugging
> purposes.
>
> They don't necessarily monitor all the patches getting merged upstream
> closely enough to realise that it impacts their debugging strategy. So
> when they notice that the output has gone from "RUN" to "RT" they're
> naturally going to ask what the difference is... and the answer is "it
> looks prettier". That's not a good enough reason.
>
> Obviously if we're printing something that's completely incorrect, or
> we can improve the message considerably, then yes, it makes sense to
> change it - but that's not the case here.
>
> Thanks for the patch, but sorry, I'm not going to apply this one.
>

Ack. It was more an illustration of my argument for preferring MR over
REL[IY] than anything else,.

--
ard.


\
 
 \ /
  Last update: 2015-09-09 15:41    [W:0.302 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site