>I've thought about SAS a bit, and I've concluded that SAS is poorly
>understood. Let me deal with that in a moment.
>
>Most of your examples of address space composition seem to exist only
>to work around the problems inherent in what you call "mapping
>capabilities." I'm about to try to convince you that mapping
>capabilities are a bad idea, and that it would be better to get rid of
>them.
>
>1. Mapping capabilities are not necessary. If your task and mine are
>cooperating, we can share a capability for an object, map the object
>independently, and collaborate. We can even negotiate with each other
>to arrive at a shared virtual address for the memory object for the
>sake of pointer references. Given this, there is no need for a
>mapping capability sent as part of a message.
There was never an argument that you can't share memory without SAS. The problem is that it's traditionallly so cumbersome that it's never done except for very specialized purposes, such as optimizing IPC or mapping files. One of the basic hypotheses of SAS is that if sharing were made much easier and more natural, people would start using it for a lot more than they do now, and in much more elaborate and efficient ways.
>2. Mapping capabilities are insecure and unreliable. I may trust you
>to provide some data to me, but not want to give you access to my
>address space (my reasons might be for fault containment rather than
>security). If mapping capabilities exist, I have no simple way to
>prevent you from mapping over critical sections of my application
>(e.g. my text section) and defeating security and containment.
That's only true in a _non-SAS_ system - in a SAS system, if you have something mapped at address X, then you are positively guaranteed that _no one_ has anything else mapped at that address. So if you receive a mapping capability, you can just plug it in and use it. (There's still the issue of whether you trust the pager that backs those mappings, of course, but that's the same in either case.)
>3. Mapping capabilities impose hidden unbounded costs on the
>recipient. Mapping an object requires system resources (to hold the
>mapping description) that the receiver may not have sufficient
>authorization to allocate.
No, the mapping description is the object pointed to by the mapping capability, and therefore it is allocated by the sender (or whoever created the mapping capability in the first place). As long as the receiver has a protection domain to plug the mapping capability into (if it didn't it wouldn't be running), there's no problem.
>Just because you want to pass me a blob of
>data doesn't mean I want to look at it in a memory mapped fashion.
>[One thing I have failed to mention in the discussion so far is that
>in my view one should be able to perform read and write invocations on
>a memory object key, so memory mapping is just one mechanism]
That's true, but only if you're thinking in conventional terms of simply passing some generic blob of data, such as the contents of a file. In a SAS system, the idea is generally that when you pass around mapping capabilities, you're passing around access to _structured_ data that can only be interpreted easily if it's mapped at certain addresses - in other words, arbitrary data structure graphs containing pointers. That data could be fully-relocated executable code ala shared libraries, trees of objects representing system state to be broadcast to everyone, name tables (why have a name server when you can go look it up yourself?), or whatever.
>All of the SAS systems I know about have intertwingled the issues of
>mappings and access rights. In these systems, not all processes can
>see all objects, and therefore they do *not* share the same address
>space.
You're confusing the terminology a little. All processes _do_ share the same address space, in that no two mappings exist for overlapping addresses _anywhere_ in the system, regardless of who can see those mappings. Processes run in the same address space, but in different _protection domains_: they can only "see" some subset of the address space. So when you receive a mapping capability, you plug it into your protection domain if you want to look at it.
>A better way to think of matters with no loss of generality is
>that SAS is a way of restricting object mappings to require all
>mappings of a given object to appear at the same virtual address.
This isn't necessarily a requirement of SAS systems - you could certainly map one object at multiple addresses if you wanted to. The point is that you're guaranteed that no one else will have any other conflicting mappings at those same addresses.
> Mapping composition can be used to implement all kinds of neat
> abstractions outside of the VM manager, such as copy-on-write.
>
>This is a good point, but I think you're assuming a particular
>solution when two are possible. One way to think about COW is that
>writable pages from the writable object are mapped "on top" of the
>non-writable pages from the backing object. If you think this
>approach is desirable, my proposal is to handle it by mapping the
>individual pages into the address space, overriding the previous
>mappings. This appears to be your assumed implementation.
>
>I suppose my view is that COW is not an attribute of the mapping; it's
>an optimization for copying a memory object. As such, it's a memory
>object artifact, not a mapping artifact. In this model, one
>implements layered memory objects. The front object is writable, but
>sparse, and the objects behind it are read only. On an object fault,
>you copy pages into the front object, thus implementing COW. The
>check for the mutable version is very simple, as the page frame
>containing the data has to be looked up in order to perform the
>mapping, and it's absence is the top-off that the page hasn't been
>copied.
I think you're right about this one - it would be cleaner to implement COW as composed memory objects than composed mappings. In fact, this is really the only way to do it right if you allow multiple mappings of the same memory object.
Bryan