l4_capability_control works well for almost all system calls
using a buffer pointer to the capability that it operates on.
Only for sharing/granting of capability lists, it is yet to be
decided how to provide a grant target id.
A 16-bit device number or id further distinguishes a device on the
system in addition to the device type. This is meant to be used for
the very first identification of the device for further probing. Any
further info is available by userspace mapping and probing.
Followed the kernel physical memory reservation convention
with devices. Devices that are possessable by userspace
are created as boot-time capabilities and placed under the kernel
resources devmem_free capability list. Any userspace container
that is defined with the possession of the device would delete the
device capability making it unavailable to further requests.
cinfo array is now freed along with other init memory.
bootmem allocator memory is reduced to be completely used up.
free boot memory now prints the used free memory as well.
The first one is related to resource recycling. The parent which is waiting its
child to exit did not delete its ktcb. Now, it deletes.
The second one is related to self destroy. The added code wakes up all the
waiters before it exits.
In the former case, when a child was exiting there was a risk of being preempted while it
was also taken away from the runqueue. In this situatuion, it may not have had
the chance of waking up the parent in case if it waits for the child to exit.
This was also true for suspend & resume so they were patched also.
If sleepers on a mutex were more than one, only one of them was woken up. This
caused the other ones to sleep forever. Now, there is not any facility to check
if there are still sleepers on the kernel space when a thread is about to unlock
a mutex. To workaround this problem, we started waking up all the threads
instead of one. This brings another problem called thundering herd but also
provides random fairness which gives more oppurtunity to a higher priority
thread to get the lock.
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)
