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.
Lots of polishing, organizational changes, bug fixes, error handling etc. are
introduced.
COPY and NEW space thread creation are allowed but not thoroughly tested yet. It
seems they will work best if the lib supports utcb virtual range management
through the mapping.
Lots of polishing, organizational changes, bug fixes, error handling etc. are
introduced.
COPY and NEW space thread creation are allowed but not thoroughly tested yet. It
seems they will work best if the lib supports utcb virtual range management
through the mapping.
Now, we support thread trees which are spanning more than one level depth. Any
thread can create any number of threads provided that they are under the limits
which are enforced by the kernel.
Also with this commit, we have almost finished supporting SHARED space thread
creation in which stack and utcb space are allocated statically.
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.
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.
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.
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.
Examples container type is designed to keep applications using codezero
userspace libraries, which is aiming to help newcomers who would like to
develop programs on top of the l4 microkernel.
Now bare bone application is one of the examples. In the near future, lots of
new programs will be introduced to show the various aspects of codezero
eco-system.
Now, we support thread trees which are spanning more than one level depth. Any
thread can create any number of threads provided that they are under the limits
which are enforced by the kernel.
Also with this commit, we have almost finished supporting SHARED space thread
creation in which stack and utcb space are allocated statically.
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.
Bahadir Balban