[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65e3bf97-8d3c-4a53-a3ad-42a16c0456d1@linux.microsoft.com>
Date: Fri, 28 Feb 2025 14:26:57 -0800
From: Roman Kisel <romank@...ux.microsoft.com>
To: Easwar Hariharan <eahariha@...ux.microsoft.com>
Cc: Nuno Das Neves <nunodasneves@...ux.microsoft.com>,
linux-hyperv@...r.kernel.org, x86@...nel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, linux-acpi@...r.kernel.org, kys@...rosoft.com,
haiyangz@...rosoft.com, wei.liu@...nel.org, mhklinux@...look.com,
decui@...rosoft.com, catalin.marinas@....com, will@...nel.org,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, hpa@...or.com, daniel.lezcano@...aro.org,
joro@...tes.org, robin.murphy@....com, arnd@...db.de,
jinankjain@...ux.microsoft.com, muminulrussell@...il.com,
skinsburskii@...ux.microsoft.com, mrathor@...ux.microsoft.com,
ssengar@...ux.microsoft.com, apais@...ux.microsoft.com,
Tianyu.Lan@...rosoft.com, stanislav.kinsburskiy@...il.com,
gregkh@...uxfoundation.org, vkuznets@...hat.com, prapal@...ux.microsoft.com,
muislam@...rosoft.com, anrayabh@...ux.microsoft.com, rafael@...nel.org,
lenb@...nel.org, corbet@....net
Subject: Re: [PATCH v5 01/10] hyperv: Convert Hyper-V status codes to strings
On 2/28/2025 12:22 PM, Easwar Hariharan wrote:
> On 2/28/2025 9:20 AM, Roman Kisel wrote:
>>
[...]
>>
>> So I'd think that the hex error codes from the hypervisor give the user
>> exactly as much as the error symbolic names do to get the system to the
>> desired state: nothing.
> I continue to disagree, seeing HV_STATUS_NO_RESOURCES is better than 0x1D,
> because the user may think to look at `top` or `free -h` or similar to see
> what could be killed to improve the situation.
>
I agree that the symbolic name might save the step of looking up the
error code in the headers. Now, the next step depends on how much the
user is into virt technologies (if at all). That is
to illustrate the point that a hint in the logs (or in the
Documentation) is crucial of what to do next.
The symbolic name might mislead; a hex code maybe with an addition of
"please look up what may fix this at <URL> or report the problem here
<URL>" would look better to _my imaginary_ customer :) That would be
as much friendly as possible, if the kernel needs to print any of that
at all. Likely the VMM in the user land if it gets that code as-is.
Thank you for the fair critique and the time!
[...]
>>> Thanks,
>>> Easwar (he/him)
>>
>
--
Thank you,
Roman
Powered by blists - more mailing lists