Re: [PATCH v2 2/3] efi: Change abbreviation of EFI_MEMORY_RUNTIME from "RUN" to "RT"
From: Ard Biesheuvel
Date: Wed Sep 09 2015 - 09:29:47 EST
On 9 September 2015 at 15:27, Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx>
>> Signed-off-by: Taku Izumi <izumi.taku@xxxxxxxxxxxxxx>
>> ---
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/