I’ll be happy to provide my input. Here’s my background: In the 90s I worked for Microsoft where I had access to source code to all OSs (Win3/95+ series as well as Windows NT) and wrote tech articles about system development issues. Since then most of my work was in RTOS based systems, developing and deploying embedded systems mostly in security environments. Device drivers, concurrency and M2M communication (all ISO/OSI levels, all media) were always both my vocation and avocation. Currently my contracts focus on Embedded Linux based systems. I am thoroughly familiar with the I/O systems of all major operating systems as well as the “back end” (device driver development). So I can look back to 30+ years of in depth involvement (from architecting to deployment/support) in systems level software.
Now to my catalogue: I believe that the “top level API” exposed to consumers of an I/O system would be pretty much off-the-shelf, meaning Open/Close/Read/Write/IoCTL. That’s well established and covers almost all use cases even to this day.
The aspect where an I/O system DOES make a huge difference, even thpough it’s hopelessly underestimated, is asynchronous I/O. So my primary requirement for an I/O system from scratch would be: Do NOT even think about select() or something compatible, even though it is tempting. Instead (even though it raises a number of spine hairs), look into Windows NT’s asynchronous I/O architecture. The one area where a server OS can score big time over the 200 pound gorillas is with some kind of support for I/O completion ports or compatible architectures which require a well thought out asynchronous I/O architecture. I’d be willing to assist if need be.
Thanks.