Updates to kip, capability and cap control man pages.

This commit is contained in:
Bahadir Balban
2009-12-04 15:44:16 +02:00
parent 2908c40816
commit 825ee3f476
3 changed files with 180 additions and 1 deletions

View File

@@ -44,18 +44,22 @@ The capability structure is defined as follows:
.fi
.I capid
denotes the unique capability ID.
.TP
.fi
.I resid
denotes the unique ID of targeted resource. The smallest resource targetable by a capability is a thread. There are also collections of targetable resources such as an address space or a container. An address space target resource implies all threads inside that address space, and a container target resource implies all threads inside that container. Quantitative capabilities such as typed memory pools do not possess a target, and therefore have an invalid resource ID.
.TP
.fi
.I owner
denotes the unique ID of the one and only capability owner. This is always a thread ID. The ownership of a capability determines who has the right to practise the capability modification privileges available over the capability, such as sharing, granting, spliting, reducing or destruction of the capability.
.TP
.fi
.I type
field contains the capability type or targeted resource type. The capability type determines the generic operations that the capability describes. For example a capability describing a system call would likely have a type name that resembles the name of that system call. See below for the list of valid capability types. The resource type denotes the type of targeted resources. In case this is a thread or a collection of threads, the type may be one of thread, address space, or container. Quantitative resources also have different types, describing the resource. Since quantitative resources such as memory pools, or memory regions are not associated with a target id, the types have no meaning for the resid field for these capabilities. See below for the full list of valid resource types.
.TP
.fi
.I access

175
docs/man/man7/kip.7 Normal file
View File

@@ -0,0 +1,175 @@
.TH KIP 7 2009-11-07 "Codezero" "Codezero Programmer's Manual"
.SH NAME
.nf
.BR "Kernel Interface Page (KIP)" " - Overview of KIP in Codezero"
.SH SYNOPSIS
.nf
.B #include <l4/api/kip.h>
.SH DESCRIPTION
The kernel interface page acts as a read-only identification structure for system-level information. Information about the microkernel version, api, and various fundamental configuration flags may be obtained via this page. Another purpose of this page is to supply system call addresses to userspace during initialization. Since the system call offsets are discovered at run-time this way, the system reserves the flexibility of changing system call offsets in the future.
KIP also provides the address of the thread-local UTCB address, and the value of this field dynamically changes as each thread becomes runnable. The KIP structure is defined as follows:
.nf
.TP
.BI "struct" " kip " "{"
.in 16
/* System descriptions */
.BI "u32 " "magic" ";"
.BI "u16 " "version_rsrv" ";"
.BI "u8 " "api_subversion" ";"
.BI "u8 " "api_version" ";"
.BI "u32 " "api_flags" ";"
.BI ""
/* Addresses of various avaiable System calls */
.BI "u32 " "container_control" ";"
.BI "u32 " "time" ";"
.BI "u32 " "irq_control" ";"
.BI "u32 " "thread_control" ";"
.BI "u32 " "ipc_control" ";"
.BI "u32 " "map" ";"
.BI "u32 " "ipc" ";"
.BI "u32 " "capability_control" ";"
.BI "u32 " "unmap" ";"
.BI "u32 " "exchange_registers" ";"
.BI "u32 " "thread_switch" ";"
.BI "u32 " "schedule" ";"
.BI "u32 " "getid" ";"
.BI "u32 " "mutex_control" ";"
.BI "u32 " "arch_syscall0" ";"
.BI "u32 " "arch_syscall1" ";"
.BI "u32 " "arch_syscall2" ";"
.BI ""
/* UTCB address field */
.BI "u32 " "utcb" ";"
.BI ""
/* Brief Description of Kernel */
.BI "struct " "kernel_descriptor kdesc" ";"
.in 6
.B };
.TP
.fi
.I magic
denotes the magic key of this kernel build.
.TP
.fi
.I version_rsrv
reserved for future use.
.TP
.fi
.I api_subversion
denotes the sub-version of API in use.
.TP
.fi
.I api_version
denotes the version of API in use.
.TP
.fi
.I api_flags
denotes the flags corresponding to this api verison.
.TP
.fi
.I container_control
address of l4_container_control system call.
.TP
.fi
.I time
address of l4_time system call.
.TP
.fi
.I irq_control
address of l4_irq_control system call.
.TP
.fi
.I thread_control
address of l4_thread_control system call.
.TP
.fi
.I ipc_control
address of l4_ipc_control system call.
.TP
.fi
.I map
address of l4_map system call.
.TP
.fi
.I ipc
address of l4_ipc system call.
.TP
.fi
.I capability_control
address of l4_capability_control system call.
.TP
.fi
.I unmap
address of l4_unmap system call.
.TP
.fi
.I exchange_registers
address of l4_exchange_registers system call.
.TP
.fi
.I thread_switch
address of l4_thread_switch system call.
.TP
.fi
.I schedule
address of l4_schedule system call.
.TP
.fi
.I getid
address of l4_getid system call.
.TP
.fi
.I mutex_control
address of l4_mutex_control system call.
.TP
.fi
.I arch_syscall0
address of l4_arch_syscall0 system call, a template for adding new system call to codezero.
.TP
.fi
.I arch_syscall1
address of l4_arch_syscall1 system call, a template for adding new system call to codezero.
.TP
.fi
.I arch_syscall2
address of l4_arch_syscall2 system call, a template for adding new system call to codezero.
.TP
.fi
.I utcb
address of utcb for this thread.
.in 8
.SH L4 USERSPACE LIBRARY
.nf
.BI ""
/* Functions to get the address of kernel interface page */
.BI "static inline void * "
.BI "l4_kernel_interface(unsigned int " "*api_version" ", unsigned int " "*api_flags" ", unsigned int " "*kernel_id" ");"

View File

@@ -74,7 +74,7 @@ field, as no method has been defined for granting a larger entity than a single
flag is planned for a future release.
If
.B CAP_GRANT_IMMUTABLE
is specified in the flags, this means the granted capability should be made immutable on-the-fly. This is required as granting needs grant capabilities on the capability, but a grantor may want to remove it as it grants it.
is specified in the flags, this means the granted capability should be made immutable on-the-fly. This is required as granting needs grant capabilities on the capability, but a granter may want to remove it as it grants it.
.TP
.BR CAP_CONTROL_REPLICATE
Replicates an existing capability. This is useful for expanding capabilities to managed children. For example, a pager may make a replica of its capability to ipc to all threads in the container, deduce the capability to only cover itself as a thread target, and share this with the container. As a result, all threads in the container may ipc to the pager but nobody else, including each other.