>KeyKOS doesn't reference count....
BTW, how does KeyKOS deal with the risk of an allocation count wrapping and "re-activating" long-dead keys?
I'll amplify on the answer that was given before (I think by Bill?).
To rescind the outstanding authorities (capabilities) to a Page (or equivalently a Node), the Page must be in core. There is a per-page book keeping structure that contains a bit that is cleared whenever the Page is rescinded (for Nodes this structure lives with the Node. for Pages it is kept in a side table on the disk). You now create new keys to the Page under the new allocation count. If any of these keys are sent to disk, the bit in the node header is set, indicating that there are outstanding keys *on the disk* to the object. If the bit is set, the allocation count *must* be incremented. If the Page goes to disk ahead of the keys the bit is set.
While in core, the keys to an object are threaded on a doubly linked list. So long as all of the keys are still in core, the list can simply be walked to invalidate the keys without increasing the allocation count.
The end result is that the count is not incremented for ephemeral objects.
OK, you're right about that one. Under Mach's current strategy, objects that get destroyed will remain allocated until all capabilities pointing to them go away naturally, which in a persistent system would create a security problem as well as a storage management problem (you can revoke the right to use an object, but you can't force the kernel memory containing the object to be releeased).
As you said, it ought to be straightforward to use an allocation count just as KeyKOS does to eliminate this problem. Be aware that this imposes some space overhead on ports, since to avoid the overflow problem you will need to be able to rescind in core, which means that ports need to be threaded.
Then the only remaining difference from the KeyKOS approach would be that kernel objects can consume different amounts of memory. The advantage would be better packing of kernel objects; the disadvantage would be that kernel memory in one zone could never be migrated to another zone (e.g. a port can never become a thread or a task).
In KeyKOS, the memory packing advantage isn't very significant. Meters don't make efficient use of a Node (they only use 3 keys), but there aren't many Meters in the system, and pretty much everything else is packed fairly densely in the usual case.
I can definitely see the benefits of KeyKOS's fixed-sized "nodes" in this respect. In fact, you're half way to convincing me that it would be a good idea to change Mach's zone allocation system to go "whole hog" KeyKOS-style, with fixed-size kernel objects...
In some ways, I regret that Nodes do not turn out to be the same size as Pages; it would simplify the disk management a fair bit.
(This assumes a priority
inheritance mechanism exists for locks in the server - does KeyKOS support
that too?)
In it's current form, KeyKOS also queues calls to a domain in FCFS order. Norm and I have thought of ways to deal with this in our discussions on how to do a real time KeyKOS, but we didn't complete the effort. Basically, the callers need to be queued in priority order and the called domain needs to run at the priority of the highest priority client blocked on the domain (or the current priority, if higher).
Jonathan