On 01/29/2019 10:43 PM, Peter Jones wrote: > Around 8 months *after* that discussion, ASWG (the keepers of the ACPI > spec) had a discussion about an ECR that added both the orientation > bits and this clarification: > > - 1-byte status field indicating current status. > + 1-byte status field indicating current status of the image. > > But that change did not change the version field. This was considered > an erratum, though I don't have enough context to know why - my guess is > that someone thought adding bits would be a harmless forward-compatible > change, without thinking about how our implementation might work with > respect to the version field or the reserved bits. Thanks for this information. I have been CC-ed on changes to this file after my own patch to it in 2016, and one thing that I noticed is that the error handling code has caused multiple issues for people; and this has happened both ways (too strict and too lax). The approach that is useful on the most hardware seems to me the best one. But that is probably a hard question to answer. > I share your dismay, but I think it's now clear that these bits aren't > intended as the status of the BGRT, but rather they merely describe the > image it refers to. With that in mind, it doesn't appear reasonable to > go on dismissing the whole thing based on the reserved bits of that > field - we can still use the image just fine. But that's just my > opinion :) I imagine the counter argument goes like this: A firmware that cannot correctly follow "must be zero", shouldn't be trusted to get the size of a potentially large memory copy during boot correct either. However, as long as the pro's and con's have been considered, I see no reason to personally object to your change. My view on what real world firmwares are actually doing is too limited to make a reasonable argument either way. Greetings, Môshe
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
