At 10:24 10/2/95 -0400, Jonathan Shapiro wrote:
>In KeyKOS, as I understand things, there was a special case mechanism
>that would allow you to hand a node to a tape I/O operation, thereby
>writing up to 16 pages (64K). I think it was assumed that the I/O
>would be page aligned, and would occur in units of pages.
Not quite. On the 370 we were EXTREEMLY blessed with having all I/O go through the 370 channel system (as an architected interface and not just a hidden DMA implementation). (I didn't think of this as a blessing at the time, but having looked at PCs, Macs, and various Unix boxes, I now do.)
With all I/O being forced into a common protocol by the hardware, it was fairly simple to map that into a domain interface. The complexities came because virtualizing 370 I/O is one of the classic sources of security penetrations. We simplely made all the techniques people had used to create security breaches illegal.
In abstract, when a domain wants to do I/O it passes a key to a segment and, in the byte string, a channel program. All the pages in the segment accessed by the channel program must be R/W. The permitted channel program operations do not include data chaining. Any Transfer In Channel (TIC) operations in the channel program are relative to the start of the byte string (and must be in the string). There are some other restrictions dealing with the details of the 370 channel program. One restriction we did not implement, but probably should have is forbiding diagnostic operations. This protection would require that the kernel know the about specific operations on each type of device, rather than just the generic operations defined by the channel architecture. Note that all data addresses in the channel program are relative to the start of the passed segment.
Because of certain implementation problems, we required that the segment be a black lss3 node key to a node containing R/W page keys. This restriction limited I/O to 64K, and toward the end was becoming a problem. The obvious solution would be to also allow lss4 black node keys to a node of lss3 black node keys. By changing some internal kernel interfaces, we could have supported arbritary KeyKOS segments, at the cost of running the segment interpretation logic. If we permitted general segments, we would had to have implemented some arbitary page limit on I/O.
I think the 370 approach solved all the problems you are addressing.
Bill
Bill Frantz Periwinkle -- Computer Consulting (408)356-8506 16345 Englewood Ave. frantz@netcom.com Los Gatos, CA 95032, USA