The second mini-panel, focusing on the protection boundary between user and kernel space (the ``red line''), was chaired by Doug Terry. It began with brief presentations from the panelists. Prashant Pradhan described how the segmentation hardware on Intel platforms could be used to isolate software modules. Godmar Back explained why the language-level security provided by Java did not remove the need for kernel-user isolation, and described how such isolation could be provided. Jon Howell presented his views on how partial evaluation (PE) in a programming language can be extended to subsume operating system services.
The discussion opened with an extended interaction between the panelists. Pradhan asked Howell whether a kernel had to be rewritten to use the PE approach. Howell replied that the PE approach was currently a pie-in-the-sky vision, but that he hoped to be able to run existing code with minor changes. Back expressed doubts about the pragmatism of the PE approach, though he agreed that it was a great vision. He had doubts in his mind about the cost of specialization, about modularity, and about concurrency. With reference to Pradhan's presentation, he mentioned that he would have like to have seen this work put in the context of single address space OSs, and better justification of the assumption that there is little cross-boundary communication. Howell agreed that PE does not eliminate the need for secure APIs. He observed that APIs do not go away in his approach, but just become specification tools.
Mike Jones expressed skepticism about the value of the PE approach in practice. He noted that at the last OSDI conference, there had been a panel on the subject of OS support for languages. In that panel, Rob Pike had confessed that a fundamental mistake in Inferno had been to assume that the OS-user boundary could be eliminated; this had seriously hurt maintability because one was faced with a sea of pointers when trying to debug. On a different point, he remarked that code did not have to be modified when moved across a kernel-user boundary; systems such as Chorus had shown how this could be done. Back agreed with Pike's observation that eliminating the kernel-user boundary resulted in a big soup of data and pointers. He also agreed with Jones' observation that code could be portable across the kernel-user boundary. Howell defended the PE approach by noting that it was important to distinguish between use of the line for specification and using it at runtime. Eliminating the line could be made automatic, using techniques such as incremental recompilation.
Robert Haas posed two questions for the panelists. Of Pradhan, he asked how his work differed from the Vino approach. Of Howell, he asked how the kernel could defend itself against buggy user code, especially since many of the obvious safety tests were undecidable. Pradhan's response was that his work was similar to sandboxing but differed in that it relied on hardware rather than binary rewriting. Howell clarified that the red line need not have to coincide with the protection boundary. He agreed that PE involved self-modification of the kernel and that this posed a robustness hazard.
Drawing upon his experience with extensibility in SPIN, Stefan Savage said that he was disturbed by the characterization of the red line implicit in the panelists' presentations. The real problem, he observed, was how wide the interface became in the presence of extensibility. The Unix interface is relatively narrow, typically 172 calls that are precisely specified. Interfaces involving 1000 or more calls are very hard to manage because they involve lots of semantic properties. There is danger in thinking that memory protection solves the problem of extensibility. Howell responded by saying no one on the panel would disagree with this point. Savage followed up with the observation that none of the panelists had addressed any of the really difficult problems that SPIN had tried to tackle. In particular, none of them had suggested how to draw the many new red lines that would be implied by extensibility. Howell replied that he didn't mean to imply that PE solved those problems exposed by SPIN. His approach was meant to fit into software engineering approaches like SPIN. Savage completed his comments by agreeing with Dave Patterson's earlier observation about the OS community having the wrong priorities.
Directing his question to Howell, Armando Fox asked whether globbing applications with runtime services leaving only a thin kernel layer didn't effectively amount to an exo-kernel approach. Howell clarified that by ``globbing'' he only meant to imply that PE did not require a fixed interface in relation to software engineering boundaries. An exo-kernel, in contrast, lowered this interface. Fox followed up by asking how a good compiler differs from what PE offers. Howell's response was that PE might recognize boundaries that current compilers might not. In any case, he felt that it was premature to comment on this question since this approach had not been implemented yet.
Dickon Reed asked what prevented 10,000 JVMs from running on a machine, a figure that Godmar Back had mentioned in his talk. Back replied that the technology wasn't there yet and that it took too much resources. He also added that the 10,000 figure wasn't made up but came from an Oracle example. Reed pressed this point further, saying that C took a while before large systems could be built with it and that it should only be a matter of time before Java was capable too. Back's response was that Java certainly wasn't there yet, and that the smallest unit of sharing being a page might lead to fragmentation problems that limited scalability.
The final question in the session was by Milan Milenkovic. He mentioned that there were two industry efforts to standardize Java runtime environments for CE and digital TV environments, ATSC DASE (American Television Standards Committee, Digital-TV Application Software Environment) in USA and DVB MHP (Digital Video Broadcast, Multimedia Home Platform) in Europe. Since these address embedded systems, there is no secondary storage and hence no support for virtual memory. To complicate matters, target platforms are real-time OSs with non-Java threads coexisting with Java threads. He wanted to know if Back's Java proposal offered hope for this type of situation. Back replied that he was only looking at all-Java environments at the moment, but hybrid solutions might be possible in the future.