On 1/12/2024 4:45 PM, Laszlo Ersek wrote: > (Independently: I think that's a valid thing to do for *SMM* drivers, > because the entry point functions of those drivers are permitted to use > both SMM and DXE/UEFI protocols. But whether the same is valid for the > *standalone* MM drivers -- that looks questionable. Standalone MM > drivers should not depend on UEFI/DXE protocols ever, IIUC.) > >> 3) The issue is patching the grammar in place, why can’t we just make a >> copy for the dispatcher grammer, and operate on the copy. Maybe via a >> copy on 1st update strategy? > > Yes, copying the depex to the heap, and patching it there, was Nhi's #1 > fix proposal. I think that could be made work. But I'm not sure if the > perf savings are worth the additional complexity. The heap allocation > (where the writeable depex would exist) would have to be permanently > associated with the loaded PE image -- because the dispatcher might need > to reevaluate the depex across multiple rounds of dispatching. So that's > a new field in some image-related structure, it also needs to be freed > upon unload (?), what if the memory allocation fails during depex eval > (just consider the depex to eval to FALSE?), etc. Doable, but hairy; not > sure if the perf is worth that effort. >
Thanks so much, Laszlo for your valuable insights. The approach #1 works for me. I will do further check for your concerns above. I'm trying your suggested patch and investigating the performance being discussed here. Regards, Nhi -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#113821): https://edk2.groups.io/g/devel/message/113821 Mute This Topic: https://groups.io/mt/103594587/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
