Comparing IPC and capability invocation

[Espen Skoglund]

[Jonathan S Shapiro]

> In my opinion, the original "name by thread-id" design in L3/L4 had two
> architectural issues:

>   1. It exposed the location of the target thread within the thread
>      table. [...]

>   2. Because the thread id's and task ids were inter-related, there
>      seemed to be a number of awkward restrictions on allocation of
>      task structures. [...]

> From various conversations, I believe that the L4 team has addressed
> the second issue, and is considering a number of solutions to the
> first, most notably "thread address spaces".

Yes.  Second issue has been address in the Version X.2 API (i.e., the
current L4Ka::Pistachio implementation).  First issue would go away if
threads were treated as virtual objects (which is something that we
are thinking about).

> I may have misunderstood, but I also believe that the power of two
> restriction on task allocation has been removed, and that any thread
> can now be associated with any task.

That is right.  You can also migrate a thread between tasks (address
spaces).




> The difference between a thread-id and a descriptor is that a
> descriptor takes the form

> 	(resource-type-code, resource-name, type-specific-data-word)

> where a resource-type-code is assigned for each kernel resource that
> is exported by means of a descriptor. Borrowing from EROS, the
> descriptor types that seem likely to be useful are:

>     void -- descriptor that responds with "unknown" to all requests
>     flexpage -- name of a flexpage
>     thread -- a thread-id (interface to the process abstraction)
>     object -- a particular object served by some thread

> In flexpages, the type-specific field holds permissions. In objects,
> it holds an object id. In threads, it might be unused.

In L4 speak the object that we operate on is a "flexpage".  A flexpage
specifies a collection of objects in the current address space and
treats this collection as a single object.  The flexpage also contains
a type.  Currently there are three types defined:

   o Page frame (i.e., memory)
   o I/O ports (ia32 only)
   o PCI Configuration addresses (ia64 only)

As you already hinted on, we (the Karlsruhe group) are also looking
into treating threads as virtual objects.  Thread IDs would then
constitute another flexpage type.  The type-specific-data-word for
threads would be something like send and receive rights, thread
create/delete rights, etc.

Using the new model, an actual address space would then consist of the
regular memory address space, the thread space, and possibly the I/O
space or PCI configuration space.  Anyhow, the ideas about what we
actually want is still a bit fuzzy, so you should take what I say with
a grain of salt.




> An added word about the 'object' type may be useful, since it
> reflects a significant philosophical difference between L4 and EROS.

> In EROS, a client invokes an object. This object may be an entire
> server (a process) or it may be a particular object that is served
> by that server. In L4, the "particular object" case is customarily
> handled by passing an object id as an argument to the IPC
> operation. One problem with this is that the object id can be forged
> by the client.

> It is not entirely clear to me whether forged object ids are a
> serious problem in the absence of persistence, but my instinct is
> that they are *sometimes* a problem, and that including them is
> therefore desirable.

Believe it or not, we have also internally been discussing/thinking
about the issue of unforgeable IDs.  But as you say, it is still
unclear whether you really *need* to support this within the kernel.
I'd really love to see a scenario that proves me wrong here

	eSk