Sharing and Protection in a Single-Address-Space Operating System

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This paper proposes to remove process specific virtual memory, and use
a single virtual memory space for all processes. This allows easy
sharing and protection mechanisms. The idea of segments and
capabilities that were introduced in the previous papers that we read
was reused. Since there is only 1 address space, pointers can easily
be passed between processes. This has enormous advantages for large,
interconnected object databases in use by numerous processes. An
application is built with segments. The application runs with threads
in a protection domain. This domain controls access to resources, and
other shared segments, or applications.

The system had an implementation of protected access points, called
Portals. This allowed non-trusted applications to call procedures in
other domains.

The normal unix linkers and loaders had to be modified to allow the
system to work. Resources were managed using reference counting, so a
Resource Group object was designed to allow flexible management of
these resources. A group can be released, and all resources in that
group are removed, even if the reference count is not zero. Some
tricks were needed to manage private data needed by processes using a
shared segment.

A prototype was built, called Opal, on top of the Mach
microkernel. Opal was a server sitting on top of Mach, that controlled
the resources, domains, and capabilities of the proposed
design. Segments were controlled similar to a filesystem with an inode
for each segment. Persistent segments were backed by a file in the
unix filesystem.

An application domain was explored and the benefits of using this os
were explained. This section was quite interesting to me, as I had
worked on this very project for many years. In my opinion, the
benefits were right on target. We had severe problems with managing
large amounts of object-oriented data, and needed high-performance for
the systems to work at all. The concept of mediators between the
performance would have worked well, and been much simpler than the
shared memory, swizzled object-database that we used instead.

I would have liked to know more about the revocation of
capabilities. This was alluded to in the last class and seems like a
difficult problem. I don't see how the solution in the paper solves it.

-- 
Greg Green

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This archive was generated by hypermail 2.1.6 : Tue Jan 13 2004 - 21:43:46 PST