[Jonathan S Shapiro]
In my opinion, the original "name by thread-id" design in L3/L4 had two architectural issues:
- It exposed the location of the target thread within the thread table. [...]
- 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