On 2/27/2025 3:08 PM, Roman Kisel wrote: > > > On 2/27/2025 2:54 PM, Easwar Hariharan wrote: > [...] > >> >> Sorry, I have to disagree with this, a recent commit of mine[1] closed a WSL >> issue that was open for over 2 years for, partly, the utter uselessness of >> the hex return code of the hypercall. > > Thanks for your efforts, and sorry to hear you had a frustrating > debugging experience (sounds like it). TBF, I didn't personally struggle with it for 2 years, IMHO, it was the opaqueness of what the value meant that contributed to user pain. > > Would be great to learn the details to understand how this function is > going to improve the situation: > > 1. How come the hex error code was useless, what is not matching > anything in the Linux headers? It doesn't match anything in the Linux headers, but it's an NTSTATUS, not HVSTATUS. Coming from the PoV of a user, it would be a much more useful message to see: [ 249.512760] hv_storvsc fd1d2cbd-ce7c-535c-966b-eb5f811c95f0: tag#683 cmd 0x28 status: scsi 0x2 srb 0x4 hv STATUS_UNSUCCESSFUL than [ 249.512760] hv_storvsc fd1d2cbd-ce7c-535c-966b-eb5f811c95f0: tag#683 cmd 0x28 status: scsi 0x2 srb 0x4 hv 0xc0000001 > 2. How having "Unknown" in the log can possibly be better? IMHO, seeing "Unknown" in an error report means that there's a new return value that needs to be mapped to errno in hv_status_to_errno() and updated here as well. > 3. Given that the select hv status codes and the proposed strings have > 1:1 correspondence, and there is the 1:N catch-all case for the > "Unknown", how's that better? > I didn't really follow this question, but I suppose the answer to Q2 answers this as well. If not, please expand and I'll try to answer. Thanks, Easwar (he/him)
