Hi there Robert,
I finally got around to looking at the uring architecture, thanks for the pointer! It is definitely an improvement and a big step towards NTs I/O completion port architecture, yet there are a number of inherent shortcomings in it which are mostly indebted to Linux’s history. Windows NT was designed from scratch, and Dave Cutler certainly knew what he was doing, so Windows NTs architecture, imho, is way superior to urings, and, as an additional benefit, maps much more natural to FreeRTOS!
One of the things I do not like about urings is that the predefined opcodes map directly to functionalities such as read, write from files or recv and send from sockets(1). I do not see any need for that whatsoever. In NT, any kernel object is waitable, and any waitable object can be associated with a completion port, regardless of what the waiting reason is, so a completion port can generically and without limits serve any synchronisation object. Decoding on where the computation sits is entirely up to the processing thread via a freely definable context structure. In fact, IOCPs can also be used outside of any I/O architecture as the concept of “waiting” on something is much more generic than I/O.
In FreeRTOS, this could mean, for example, that any queue-derived object could be attached to a completion port, regardless of whether the queue implements a mutex or a sempahore used to implement, e.g. socket or file system notification or anything else that a queue can implement. No need to distinguish between high level functionalities or semantic interpretations of the wait/suspend reasons. This could easily be added via a compound context structure, but in my experience, I do not see a big need for it. By predefining (thus limiting) semantics, it is harder to add new ones without the need for a tedious and resource-and time consuming certication/review process.
I have more than once toyed with code that would implement “pure” IOCPs on FreeRTOS, and I do not believe it would be that hard to implement.
(1) From what I understand about Unix/Linux, the need for separate sets of I/O API functions for network and file I/O is rather arbitrary and has been debated heatedly over time, with several attempts to provide a unifying API over time. It is hard for me to understand why the uring API now goes back to that historical mess.