Handle DerefOf buffer fields#317
Conversation
| context.start(OpInFlight::new(opcode, &[ResolveBehaviour::TermArg, ResolveBehaviour::Target])) | ||
| } | ||
| Opcode::DerefOf => context.start(OpInFlight::new(opcode, &[ResolveBehaviour::TermArg])), | ||
| Opcode::DerefOf => context.start(OpInFlight::new(opcode, &[ResolveBehaviour::SuperName])), |
There was a problem hiding this comment.
Are you sure this should change to SuperName? The spec has TermArg (https://uefi.org/specs/ACPI/6.6/20_AML_Specification.html#defderefof and click ObjectReference)
... I guess it's to avoid repetition of the field/buffer read code from the ResolveBehaviour::TermArg => { arm of the match behaviour block?
If so I understand the motivation and am not against it but I think it'd be worth a comment to explain
There was a problem hiding this comment.
It's indeed intentional as resolving this as TermArg would eagerly read BufferField and FieldUnit objects before DerefOf executes. I added a comment.
There was a problem hiding this comment.
Yep, that makes sense! Thanks!
|
Apart from my question above this looks good to me! Especially appreciate you:
Isaac, to save you a little time I can tell you I merged this into my fork and the code and tests all seem to work just fine |
Allow DerefOf to read directly from BufferField objects. This matches AML patterns emitted by firmware that creates named fields over buffers and then uses DerefOf(field).
|
Great, thanks for the PR! And thank you to @martin-hughes for his review and testing |
3 participants
Allow DerefOf to read directly from BufferField objects. This matches AML patterns emitted by firmware that creates named fields over buffers and then uses DerefOf(field).