On 3/7/19, Gernot.Heiser@data61.csiro.au <Gernot.Heiser@data61.csiro.au> wrote:
Folks might be interested in this blog: https://microkerneldude.wordpress.com/2019/03/07/how-to-and-how-not-to-use-s...
The IPC transport layer for UX/RT will follow these rules for the most part AFAICT (although there is one possible caveat). It will use an unstructured call-return model in which every IPC transport layer call is either a read that requests a specified number of bytes with a specified offset and expects either data or an error code, or a write that sends a specified number of bytes with a specified offset and expects a status code (unlike most IPC transport layers for microkernel OSes there will be no support for arbitrary typed messages or marshalling, with both of those left to higher-level libraries). There will be a short message API using abstract message registers (which may or may not be directly mapped onto seL4 message registers depending onto the situation), a long message API using a shared buffer, and a traditional Unix-style read()/write() API that may use either, with all three being interchangeable (messages will be automatically copied when necessary by the transport layer). All IPC endpoints will be presented as named files much as in Plan 9 (UX/RT will go even further in its file orientation in that all process memory will be presented as files as well). The raw seL4 IPC API won't be exposed to user processes, since the transport layer API will map onto it pretty closely, and I want UX/RT to have only one IPC transport layer that is compatible even between processes using different APIs (and reads and writes will not be required to go through an intermediary server so there will be no performance reason to bypass the transport layer). The caveat is that seL4 may have SMP scalability issues with a general-purpose OS running a wide variety of applications on a wide variety of hardware like UX/RT will be. In a general-purpose OS, processes shouldn't have to be statically assigned to run on specific cores (although of course that should be an option), and they shouldn't have to care about which core a server is running on. Passive servers don't completely solve the problem since I want UX/RT to be compatible with code from other OSes that don't have such a concept, and it should be possible for arbitrary processes (even something like a shell script) to serve filesystems as in QNX and Plan 9. Linux in a VM is not a substitute for native Unix compatibility since my goal is to make an advanced Unix-like OS in which all processes benefit from safer code and extensible multi-server architecture, rather than forcing anything not specifically ported to run in a "penalty box" where it still suffers from most of the problems with conventional OSes. If I can't make seL4 scale well for UX/RT I may end up having to fork it. Of all the existing open source microkernels it is still the closest to what I consider ideal in terms of architecture, despite the possible SMP scalability issues.