[cap-talk] Ports term (was: Persistence as a category, danger, PLASH )

Thu Mar 13 16:09:03 EDT 2008

On 3/13/2008 11:15 AM, Karp, Alan H wrote:
> Jed wrote:
> 
>> How do people feel about the "ports" term?
>>
> Why do you need a new term, especially one with connotations that might confuse some readers?

I guess that makes sense.  This area of "ports" based
systems was quite an active one at one time.  Just to
be clear, what I was asking about was whether it might
make sense to use the term "port" as an alternative
to "non persistent capability".

I think I'll do a real quick (read Web) literature search on
this area to see what I come up with (below).  Having done
so I agree that there isn't enough value gained from the
historical developments with the "port" term to make
it worthwhile as an alternative for "non persistent
capability".

Here are notes on my review - which I find interesting
but others may not:

1.  I notice that the first system that I know of in this
area, DEMOS, used the term "link" which it called
"capability-like".  Here is the abstract from "Task
Communication in Demos" (1977):

"This paper describes the fundamentals and some of the details of task
communication in DEMOS, the operating system for the CRAY-I computer being
developed at the Los Alamos Scientific Laboratory. The communication mechanism
is a message system with several novel features. Messages are sent from
one task to another over links. Links are the primary protected objects in
the system; they provide both message paths and optional data sharing between
tasks. They can be used to represent other objects with capability-like access
controls. Links point to the tasks that created them. A task that
creates a link determines its contents and possibly restricts its use. A link
may be passed from one task to another along with a message sent over some
other link subject to the restrictions imposed by the creator of the link being
passed. The link based message and data sharing system is an attractive
alternative to the semaphore or monitor type of shared variable based operating
system on machines with only very simple memory protection mechanisms or
on machines connected together in a network."

Forest Baskett was the primary author

2.  I think Perseus was still using the "link" term by 1980 (after Demos).
I found this discussion in their paper of interest (though long):
_____________
The use of connections was dictated primarily by the decision
to provide capability-like protection. The use of link-ids is
notably different from systems like RIG or Thoth in which all
communication ports are global identifiers. In RIG, the use of
global, location-dependent identifiers was reported to be a major
headache, and, indeed, was a principal motivation for the
integration of ports in to Accent [38,19]. No such problems were
reported in Thoth, largely because Thoth supported an extra level
of low-level naming, location-independent logical process
identifiers. There arc two issues involved here, neither of which
have, in our opinion, been given a substantial treatment:

A. Is there a substantial gain in building protection in at the
message level or would be it be better to provide that
protection on the process level, based on end-to-end type
arguments [2 l]? Not all checking can be done at the
message level. because in general, the message level does
not possess enough knowledge to do so. Therefore, the
receiving process will, even in a protected system, still have
to do some checking of its own. So one can wonder
whether there is any merit in doing checking at the message
level at all, since the effort probably will have to be (at least
partially) duplicated at the process level.

B. What cost is involved in using local identifiers? What
percent of the time does the kernel spend in mapping
identifiers from one level to another? One must bear in
mind that interprocess communication is a heavily-used
utility and therefore it should be made as efficient as
possible.

Accent may help answer some of these questions.

Assuming that protected communications paths (connections)
arc a good idea, a third potential problem with links is that they
are tightly coupled with processes. That is, the only entity that
can receive a message from a link is a process; in particular,
communication with the kernel is via system calls distinct from
the IPC machinery. This may be warranted under the argument
that services with substantially different semantics and
performance characteristics should be accessed with substantially
different mechanisms.

In Accent, on the other hand, ports and processes are totally
independent. It is the port that represents the service, not the
process. Thus, a port can be used to specify kernel objects, such
as interrupt handlers, or an operating system could implement
ports without implementing processes. This scheme eliminates
the need for virtually all system calls other than those for sending
and receiving messages. Moreover, the separation of
communication and function allows the service to migrate
without clients being aware of the migration, and it allows for the
explicit management of communication bctween two parties by
an intermediary (such as a debugger or performance monitor).
________________

3.  It seems that when it comes to Accent (later to become
Mach I guess?  Rashid's project):

http://www.cs.ucsd.edu/classes/wi08/cse221/papers/rashid81.pdf

"Accent: A communication oriented network operating system kernel"

they did start using the term "port":
__________
The basic transport abstraction of the IPC is the notion
of a port. A port is a protected kernel object into which
messages may be placed by processes and from which
messages may be removed. All services and facilities
provided by a process are made available to other
processes through one or more ports.
_________

Hmmm.  Their terminology seems a bit confusing to me
in that they also use the term "capability", e.g. consider:
_______
Ports cannot be directly manipulated or named by a
process. Instead, the kernel provides processes with a
secure capability to send a message to a port and/or
extract (receive) a message from it. This capability is a
local name for a system object, much in the way a UNIX
file descriptor is a local name for a system maintained
file, pipe, or device [I 1 ]. Port capabilities may be passed
in messages, handed down to process children, or
destroyed. A given process may have only one local
name for a given port at a time. Whenever a port name
is passed in a message the system kernel must map that
name from the local name space of the sending process
into the name space of the receiving process.
_______

They seem to distinguish between the "port" and a
capability to a port.  However, I don't see any
mention of capabilities to anything besides ports.
That is, the port itself seems to be the object
reference.

4.  Mach - here is the key I think to what
distinguished Mach from Accent:

(from: http://library.nocrew.org/lib/os/Mach.txt)
___

Mach traces its ancestry to the Accent operating system developed at
Carnegie Mellon University (CMU). Although Accent pioneered a number
of novel operating system concepts, its utility was limited by its
inability to execute UNIX applications...
____

So Mach became a "kernel" for Unix - in which role, not
surprisingly, it had performance difficulties and
difficulties in demonstrating added value.  The kernel
is, after all, hidden within the system isn't it?

5.  I couldn't find the paper: "RIG, Rochester's
Intelligent Gateway".  The ACM apparently only
has the paper's abstract which is meaningless.

6.  I didn't take time to search out Thoth, though
perhaps for our historical review we should.

--Jed  http://www.webstart.com/jed/