Ideas for IPC implementation

[bSchnepp]

Right now, threads store their information using a useful register in userspace, so there is a known location where exactly one page of data is available, and this can be forwarded to other processes to do some useful zero-copy stuff with.

By convention, IPC generally follows the same protocol with a small header at the start and then an actual description of data, but this isn't currently managed or checked at all by the kernel.

Something which may be nice to allow for additional data to be sent in one go would be to add something sort of like block pointers in a filesystem, so that the data section can instead be made up of a series of 8-byte pointers (or 16 byte, with top all 0s, for futureproofing?), and each of these can contain a message in our IPC format serially.

This would require some extensive work to prove that IPC here is never invalid, and would have some questions to ask about proper behavior of a process if some individual messages (but not all of them) are dropped, rejected, etc.

[bSchnepp]

At a minimum, some future IPC primitives should include things like anonymous events, semaphores, and possibly some other primitives for device memory synchronization. Ports are more or less like 90% of what we would ever need though.

[bSchnepp]

One way to get around the limit is to have the kernel parse every message that comes through, and validate that some portion of it's headers are valid: this would be better than actually enforcing IPC constraints in the kernel, but feels a little too Mach-y for me.

Ideally, the kernel shouldn't be involved in IPC at all (other than actually facilitating the whole process), and if we could safely get away with it, just sharing memory directly between processes would be nice: we could just have a special flag in the header determine what kind of message this is, and what invariants the kernel should enforce.