[Prev][Next][Index][Thread]

Re: OSKit and processes


> I want all processes 
> to be in the same flat address space but protected from each other, as 
> opposed to how Unix does things where everything is in its own address 
> space.  I am still in the early planning stages though and would love to 
> hear other people's analysis of the pros and cons of this memory model.

In OS design this is a reasonable but fairly radical approach, called
a "single address space" design.  There is a lot of literature on it.
It was very hot about six-10 years ago but has fallen out of fashion.
SAS tends to go along with single-level stores and persistent object
systems, because it enables many of their benefits, but is not
necessarily coupled to them.

http://www.cs.dartmouth.edu/cs_archive/sasos/sasos.html contains
pointers to some dead and living SAS projects, an extensive
bibliography, including abstracts, and and mailing list archives.  The
list is basically dead now, since as I said interest has mostly moved
on.  But it will probably come back; these things go in cycles.

In the next SOSP (http://www.diku.dk/sosp99/), a premier OS
conference, there is paper on a related topic that would probably be
useful to you.  It's about combining the x86's support for segments
and pages to extend the kernel with little bits of untrusted code
(supposedly run in a restricted execution environment).  "Integrating
segmentation and paging protection for safe, efficient and kernel/user
extensions."  T. Chiueh, G. Venkitachalam, P. Pradhan (State
University of New York at Stony Brook).

The final SOSP papers were all submitted yesterday, so if you
write to the author or check his Web site I am sure you
can get a copy.  It's full of low-level grungy details.

'Mungi' (UNSW, Australia) is one SAS project that I think is still
active or semi-active.  Another one is 'Nemesis' (Cambridge, UK).
You can find pointers on the Dartmouth page above.

The OSKit would provide the needed infrastructure for such
a SASOS but be warned that this stuff is complicated and
you'd best do some reading and studying of others' code first.
Follow-Ups: