Evaluate ideas for ports

[bSchnepp]

At a high level, IPC needs to operate with as little interference from the kernel as possible. Poking around for how similar systems have worked, a reasonable implementation appears to be:

• Have a concept of named services by the kernel, backed by an anonymous IPC primitive. These do not have any permissions associated with them (permission checking is expensive, and we want users, permissions, etc. to all be in userspace anyway)
• Anonymous IPC primitives can be created by anyone at any time for any reason, and can be forwarded over other IPC primitives to allow a connection to them
• Processes communicate typically via these anonymous IPC primitives. As anyone can create them and use them, provided they have access to said resource.
• Thus, the named services are useful to construct a service which allows for two processes who do not have a direct connection between them to have a shared point where a connection can be forwarded between them.

A problem now arises: it appears that the only use for named services is setting up these primitives to begin with, so why have them at all? These (annoyingly) open the possibility of conflating a kernel primitive with a structure that really only exists in userspace, between programs which happen to agree on a communication protocol based on the data structure that does actually exist between them: a single, shared read/writable page, which may or may not be structured in any particular way.

In any case, it appears that actually assigning them a name may be somewhat redundant: assigning them a specific integer for their ID would be equally effective, but since pantheon already asserts all names must be precisely 8 characters and are treated as a big endian integer anyway, this is already essentially how this is done.

[bSchnepp]

A naturally arising problem out of this is that having named ports exist in the first place (and as a kernel primitive) is that formal verification of all of this becomes more difficult: if we started with model checking, we would have to allow for such things (and to take up some space of names). Even if this were modelled with up to 64 possible names (represented as a 6 bit bit vector), our state space would explode even higher, rather than the simple 1 page read/write sharable content already there, plus interactions with anonymous interfaces to use them.

[bSchnepp]

On the other hand, a good reason to keep named ports is if a future service does need to make use of them (ie, a globally accessible service for obtaining user info, which doesn't need permission checking).

[bSchnepp]

Appropriately, that would be helpful for #10