On 25/01/2024 15:06, Ni, Ray wrote:
I agree with you about the above PI spec clarifications.
Would you like to write a PI spec ECR?

I am not a UEFI Forum member, so I don't think I have standing to do this. (I also don't have the spare time to do this for free, sorry.)

But I do not think the PI spec version stored in the PI system table needs to
reflect whether a DxeCore implementation follows the clarification.

Since the DxeCore::CoreTimerTick() implementation raises TPL to HIGH in the 
very first version created
in more than 10 years ago, I think it's safe for TimerInterruptHandler() 
assumes CoreTimerTick() will
raise TPL to HIGH so that TimerInterruptHandler() does not need to raise TPL to 
HIGH.
(I agree changing the spec version is the most correct way if we review the 
problem in a very theorical way.)

I don't see any call to RaiseTPL() in the current version of CoreTimerTick(), unless this is implicit in the use of CoreAcquireLock()?

I really want to keep the UEFI world simple with the bug fixed.

I definitely agree with this aim!  :)

(The cost is assumption on existing DxeCore::CoreTimerTick().)

For me, the problem is that we can't assume that it's the EDK2 implementation of CoreTimerTick() that is being used. It's perfectly legitimate for an implementation to not use EDK2's DxeCore, and to provide a NotifyFunction that *requires* being called with the TPL already raised to TPL_HIGH_LEVEL.

If we're not worried about maintaining conformance to the published specifications, then there are several very breaking changes I'd like to make, starting with the USB I/O protocols. :)

Thanks,

Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114427): https://edk2.groups.io/g/devel/message/114427
Mute This Topic: https://groups.io/mt/103950154/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to