It's very specific for my use of building it for my site, but I've put the Doxyfile at https://bsdio.com/edk2/docs/master.doxyfile . You'll want to change things like the output directory, which is

Personally, I've found Doxygen a great help in understanding EDK2. I've been maintaining a build of the documentation at https://bsdio.com/edk2/docs/master/index.html for a few years. I think I've

Started looking at EDKII code about two months ago. One of the things I still haven't figured out is how to read code effectively, possibly with the help of cross referencing tools. Haven't got much

I just noticed this never got committed: https://github.com/tianocore/edk2/blob/master/.gitmodules still shows the old URL. -- Rebecca Cran

This is an unfortunate oversight in the architecture, but RNDRRS most certainly does not return a true random number. RNDR and RNDRRS both return the output of a DRBG (pseudo RNG), and the only

Right, I hope to propose some patches after the stable tag. Thanks, Paolo -- should not be your job, but I'll gladly take your help. Seeing a few examples from you will hopefully teach me some

I think the first step should be to introduce the new fence primitives and fixing MemoryFence to be what it says on the tin. I can volunteer for the work of removing volatile once those are

Yeah, also given that the bugs around this are subtle. And, it is a non-trivial effort to test all the affected pieces of logic. Just thinking out aloud -- maybe the thing to do might be to

The ARMv8.5 RNDRRS instruction appears to be missing from the diagram on page 11 - it has RngLib|RNDR, which is listed under PRNG, but RNDRRS returns a true random number. From the Arm ARM: "Returns

Laszlo, I think it makes sense to “break this up”. Seems like we need correct primitives and documentation on how to use them. It is easy enough after that to use code review to make new code

Given the actual amount of MemoryFence() calls and "volatile" uses in edk2, it's actually a pretty large undertaking to "fix" these issues. I don't foresee a quick resolution here, especially if I'm

Thanks for the explanation. That does sound like a pain to work with. I wonder if there are CPUs with ordering primitives fine-grained enough where this would be useful. Ankur

AFAICS, the various versions of MmioRead, MmioWrite defined in MdePkg/Library/BaseIoLibIntrinsic/IoLib.c or MdePkg/Library/BaseIoLibIntrinsic/IoLibNoIo.c are effectively what I was proposing as well:

The problem is that the ordering does not extend to relaxed (or even acquire/release) loads and stores. Therefore *every* store that needs to be ordered before a seq_cst load must also be seq_cst.

I see. Yeah, this ordering does seem like easier to work with. So I don't quite see what would make "memory_order_seq_cst" harder? From the spec

Well for the IoLib that is + ~100 clock cycles for every MMIO read/write so that makes me a little nervous. Thanks, Andrew Fish

I'd say it is because we are reasoning about how accesses to the data are ordered, not about the data itself.

( Slightly off-topic, but I wonder why this approach (code annotations) has proved more effective / successful, with atomics, than annotating data. Usually it's recommended to put emphasis on data

I disagree, as long as we talk about CPU synchronization through variables that live in RAM. "volatile" has a use case, yes, but not for this purpose. The Linux document Paolo referenced earlier

Well, that could certainly be a next step, but I intentionally left it out of my proposal to Laszlo. The reason for that is that the fences are already enough to wean the edk2 codebase from volatile