IPC capability targets current container, current pager's space,
another container, or another container's pager.
Any other capability (e.g. thread_control) targets current container
or pager's space.
In order to do resource recycling we need a table structure. In the search of
one, we concluded that a task list will make things easier when we start adding
COPY and NEW space handling.
This commit is for utcb recycling. Now, it does not support thread trees more
than one level depth. Thus, to be able to test it, we preferred l4thread_destroy
instead of l4thread_exit.
It is not very straightforward to reach a capabilities list. We
now use a single function to find out a capability by its id and
its list, since the two are used frequently together (i.e. cap
removal and destruction)
Implemented a protocol between a client and its pager to
request and get a capability to ipc to another client of the pager.
Pager first ensures the request is valid from its client.
It then tries to use a greater capability that it possesses, to
produce a new capability that the client requested. Once the kernel
validates the correct one and replicates/reduces it to client's
need, it grants it to the client.
Pager handles client capability requests by using one of its own
capabilities to create a new one that suits the client's needs.
The current issue is that the kernel can have multiple caps and it
may not know which one is suitable for using to create one for the client.
The kernel knows this very well, so the solution would be to attempt to
use capabilities that roughly match (i.e. by type) and leave it to
the kernel to decide whether it is any powerful to suit client's needs.
In posix, test0 makes inter-space ipc for testing extended ipc. This
correctly fails when only the cap to ipc to pager is given to all tasks
in the container.
In order to overcome this problem, the tasks who fork for doing ipc to
each other make a request to the pager to get capabilities to do so.
Pager finds its own widened ipc capability over the container, replicates
it, validates and reduces it to desired boundaries (i.e. just ipc betw.
two spaces) and grants it as IMMUTABLE to requesting tasks.
This protocol may be useful in implementing a client/server capability
request relationship. Code builds but untested.
Modifying task_virt_to_page() so that it takes into account page
protections. If mm0 writes to a task page that is meant to be
read-only, (e.g. the zero page) the design is broken.
Every access to a task's page will take the page fault route,
and the page fault handler will return the page instead of 0.
UTCB support has beed added. It has the same drawback as in the stack support:
the area in question has to be already mapped-in.
There are also some minor fixes for the stack support and the utcb common helper
routines.
Utcb support has beed added. It has the same drawback as in the stack support:
the area in questen has to be already mapped-in. There is some basic
infrastructure for utcb to support mapping but it is far from being complete.
MAPPING_ENABLE symbolic constant controls this behaviour.
There are also some minor fixes for the stack support and the utcb common helper
routines.
The difference between this thread library and the existing ones like pthreads
is the necessity of informing the library about the address range of the stack
and the l4 specific utcb. Utcb has not been supported yet. As for stack, there
is also a drawback: library does not support mapping. In other words, the stack
area in question has to be already mapped-in. Thus, for now we only support
threads sharing their address spaces: TC_SHARE_SPACE. In this respect, it is
very similar to pthreads.
bss segment may have some of it at the end of data, but the bits
that lie on a new page need to be mmaped as anonymous. When this
occured we were not passing the new page boundary but the last
data page where bss started
This is one of the steps we need in the process of providing a similar interface
for thread creation which can be found in the mainstream operating systems like
Linux.
