Having dug my out of the chaos of 12 people in the house over Christmas, I finally got a chance to read the draft, red pen in hand. Comments:
2.1 What coherency model is implemented. Sparc, for example, has three.
2.1 I would have understood the mapping discussion better on the first pass if the paper made it clear that DIMSUM supports mapping a window on a segment, and not a segment itself. (A difference from Multics.)
2.1 If several processes share an address space, then the issue of who gets the address fault becomes important. My gut feel is that the address space keeper should get it with a way of passing it to/ invoking the process keeper if the address space keeper is unwilling to fix the problem.
2.2 Does it make sense for threads from multiple architectures to run within a single address space? I would think that in all cases, the machine languages would be different, and so would require separate address spaces, if only for the interpreter segment.
2.2.2 Can the authority of the address space key be subsetted? Can a user build a synthetic address space key that acts as an address space key in a process, but still allows the user's program to interpret all the key invocations. Allowing synthetic objects was an early KeyKOS design goal.
2.2.1 Footnote 8 It can trap to the process keeper with an invalid fault. In general, can the segment extension fault be used to implement a "allocate on write" policy?
2.3 What is the contract with a real time process that doesn't want to use the CPU? Can it accuse DIMSUM of failing to meet its part of the contract?
2.3 Dynamic Priorities - They can be used for policies such as, "make the top window run well", and "make a process that is sometimes CPU bound and some times I/O bound a good citizen".
2.3 N.B. KeyKOS only used Schedule groups for cleanly stopping a group of processes.
2.3.2 Perhaps an exception after a certain amount of computation would be useful. Like running out your meter in KeyKOS.
2.4.2 Key Table Exceptions. Addressing a key table where your process has no key table key needs to send an exception to someone. Perhaps the process keeper is the logical candiate.
2.5 Footnote 9 - KeyKOS defined two address space keys for the 88000. I'm not sure the kernel accually worked because universally people would store the same key in both slots. I am not sure that first class support for Harvard architecture is worth it. UNIX certainly won't use it.
2.5.1 2nd paragraph after the bullets says "A virtual processor in the halted state..." is this the same as the disabled state? Just how are process traps handled? KeyKOS gets machine dependent in this area, in an attempt to provide as much debugger support as the underlying architecture will allow.
3. Send Keys and Receive Keys seems to imply that only the high bit of the 5 bit index resides in the message control word.
5. Where does the recursion of having to call a segment keeper to resolve missing segment data end? Who resolves the segment faults of the segment keeper?
6. What are "core resources"?
7.2 Void Key - What happens when you halt? How do you test for a void key? The KeyKOS DK0 approach didn't always trap you. If you accepted the return code, then you could test for void as part of your normal outcome testing.
7.2 Zero Segment - What are backing heaps?
9. Is there a reference for the Xanadu information architecture?
9. The way I read this, each server that wishes to authenticate its clients has a segment key to the "offical" user description segment, and can map it and see all the user authentication data. This problem is a specific case of a more general view that servers are more trusted than clients.
9. What does it mean that user objects are immutable? The underling segment certainly isn't. How do you throw a user off the system?
I also found some low level english type errors:
2.2.3 Second paragraph has some english problems. 2.3 Second paragraph has Realt-time. 3. FIrst paragraph says "Operations sucha s..." 7.1 first paragraph has "shedule" ----------------------------------------------------------------- Bill Frantz Periwinkle -- Computer Consulting
(408)356-8506 16345 Englewood Ave.
frantz@netcom.com Los Gatos, CA 95032, USA