Searched refs:capabilities (Results 1 - 16 of 16) sorted by relevance

/seL4-refos-master/kernel/manual/parts/
H A Dnotifications.tex19 \obj{Notification} capabilities can be badged, using
22 capabilities (see \autoref{sec:ep-badges}). As with \obj{Endpoint}
23 capabilities, badged \obj{Notification} capabilities cannot be
24 unbadged, rebadged or used to create child capabilities with
63 specific badge (or range of badges) for capabilities to the bound
H A Dcspace.tex12 capabilities that the thread possesses, thereby governing which
15 Recall that capabilities reside within kernel-managed objects known as
17 contain a capability. This may include capabilities to further
24 capability. Threads refer to capabilities in their CSpaces (e.g. when
27 of the indices of the \obj{CNode} capabilities forming the path to the
34 Recall that capabilities can be copied and moved within CSpaces, and
36 \autoref{sec:cap-transfer}). Furthermore, new capabilities can be
40 these copied capabilities and the originals. The revoke method
41 removes all capabilities (in all CSpaces) that were derived from a
50 addressing capabilities withi
[all...]
H A Dipc.tex21 capabilities.
32 tag consists of four fields: the label, message length, number of capabilities
34 message length and number of capabilities determine either the number of
35 message registers and capabilities that the sending thread wishes to transfer,
36 or the number of message registers and capabilities that were actually
41 manner in which capabilities were received. It is described in
59 endpoint capabilities received}
100 of data and capabilities (namely the IPC buffer) to be transferred between two
124 Endpoint capabilities may be \emph{minted} to
133 capabilities wit
[all...]
H A Dbootup.tex23 which contains capabilities to the initial
30 The first 12 slots contain specific capabilities as listed in
73 which capabilities are stored where in its CNode, the kernel provides
81 capabilities, it also informs the initial thread about
107 \texttt{seL4\_SlotRegion} & \texttt{ioSpaceCaps} & I/O space capabilities for ARM SMMU \\
111 \texttt{seL4\_SlotRegion} & \texttt{schedcontrol} & seL4\_SchedControl capabilities, one for each node (MCS only). \\
112 \texttt{seL4\_SlotRegion} & \texttt{untyped} & untyped-memory capabilities \\
127 \texttt{extraBIPages} slot region gives the frames capabilities for the pages that make up
145 The capabilities in \texttt{userImageFrames} are
148 The capabilities i
[all...]
H A Dobjects.tex33 \item[Reply objects] (MCS only) are used to store single-use reply capabilities,
43 \item[Capability spaces] store capabilities (i.e., access rights) to
61 capabilities. This enables software-component isolation with a high
74 capability system, where capabilities are managed by the kernel.
78 slots, where each slot may contain further \obj{CNode} capabilities. An
87 kernel service. Furthermore, capabilities can be \emph{minted} to
93 authority. Revocation recursively removes any capabilities that have
95 capabilities through the system is controlled by a
116 number of data words and possibly some capabilities. The structure and encoding
119 Threads send messages by invoking capabilities withi
[all...]
H A Dio.tex20 \obj{IRQHandler} capabilities represent the ability of a thread to
40 When the system first starts, no \obj{IRQHandler} capabilities are
47 resulting capabilities as appropriate. Methods on \obj{IRQControl} can
48 be used for creating \obj{IRQHandler} capabilities for interrupt sources.
56 In addition to managing \obj{IRQHandler} capabilities, x86 platforms require
76 Access to I/O ports is controlled by \obj{IO Port} capabilities. Each
103 \obj{IO Port} capabilities to sub ranges of I/O ports. Any range that is issued
133 \obj{Page} capabilities are used to represent the actual frames that are
223 All the StreamIDs and context banks are accessible via capabilities. Control
224 capabilities ar
[all...]
H A Dvspace.tex22 capabilities to the required objects.
48 By making these cache related operations invocations on page directory capabilities in addition to
49 the page capabilities themselves, the
52 to those capabilities directly.
H A Dapi.tex200 Too few message words or capabilities were sent in the message.
H A Dthreads.tex371 invalid capabilities silently fail). In this case, the capability
/seL4-refos-master/kernel/libsel4/arch_include/x86/sel4/arch/
H A Dbootinfo_types.h16 seL4_Uint32 capabilities; member in struct:seL4_VBEInfoBlock
/seL4-refos-master/libs/libsel4/arch_include/x86/sel4/arch/
H A Dbootinfo_types.h16 seL4_Uint32 capabilities; member in struct:seL4_VBEInfoBlock
/seL4-refos-master/projects/refos/design/
H A Dintro.tex45 \refOS is designed with an \Lf family microkernel in mind and assumes the existence of features such as interprocess communication and capabilities. This section describes these assumed features. These features are available in advanced \Lf-based microkernels such as \seLf.
57 \textbf{Reply} protocols occur via reply capabilities. A call via invoking a synchronous endpoint generates a reply capability for the server to respond to the caller. The callee can send a response to the original caller and unblock the caller by replying with the reply capability. Reply capabilities are guaranteed either to succeed or to fail and not to block. Non-blocking replies are required for a trusted server to safely reply to an untrusted client.
67 \refOS assumes the microkernel that it runs on provides support for a capability-based access model, and more importantly, the ability to transfer badged capabilities via interprocess communication.
71 \refOS is designed under the assumption that synchronous call and reply interprocess communication messages may contain capabilities. \refOS also assumes that there is some way to store a minimal amount of immutable information in such capabilities and that receiving processes may read the immutable information from the capabilities that they receive via interprocess communication.
73 In the sample implementation given using the \seLf microkernel, these assumptions are implemented as kernel interprocess communication endpoint \emph{badges}. Endpoint capabilities may be badged with an integer, and the badge of an endpoint once it has been set is immutable. When a badged endpoint capability is sent along the endpoint that it is pointing to, the kernel \emph{unwraps} the badge to be read. Only the process which created the badge can read it back via interprocess communication. \refOS makes heavy use of these badges in order for servers to track server objects (such as windows and dataspaces).
88 Synchronous and asynchronous call and reply operations may be implemented directly using the microkernel features described above, such as interprocess communication, capabilities, capabilities vi
[all...]
H A Dinterface.tex24 Note that in implementations, objects may be merged in some cases. For example, the process server's \obj{liveness}, \obj{anon} or \obj{process} object capabilities may be merged for simplification.
46 This section describes a number of important protocols that \refOS employs. As noted in \autoref{mNotation} of this document, each protocol description consists of the server that is receiving and handling the method invocation via an endpoint, the name of the interface that the server implements, the name of the method call and the arguments that are passed to the method call and the return values, output variables and/or reply capabilities of the method invocation. Note that for simplification some method names differ slightly between this document and \refOS's implementation.
261 Unregister a server under a given name so clients are no longer able to find the server under that name. This method invalidates existing anon capabilities.
H A Dprotocol.tex421 A process control block data structure should bookkeep its address space (capability space and virtual memory space), its threads and the clients it is watching. \refOS also contains parameter buffers, notification ring buffers, the process operating system capabilities bitmask, the parent process's ID, the debug name and a number of other bookkeeping parameters.
/seL4-refos-master/projects/refos/impl/apps/nethack/src/nethack-3.4.3/doc/
H A DGuidebook.tex261 you will vary from port to port, depending on the capabilities of your
2581 Note that this has nothing to do with your computer's audio capabilities.
2992 capabilities of their screen-readers to be quite valuable. Be certain to
/seL4-refos-master/apps/nethack/src/nethack-3.4.3/doc/
H A DGuidebook.tex261 you will vary from port to port, depending on the capabilities of your
2581 Note that this has nothing to do with your computer's audio capabilities.
2992 capabilities of their screen-readers to be quite valuable. Be certain to

Completed in 163 milliseconds