Lines Matching defs:and

31 % FIXME The references to mint in the following paragraph and previously in
34 Recall that capabilities can be copied and moved within CSpaces, and
40 these copied capabilities and the originals. The revoke method
51 capability and CSpace management, before discussing how capabilities
55 \section{Capability and CSpace Management}
59 CSpaces are created by creating and manipulating \obj{CNode} objects.
61 that it will have, and this determines the amount of memory that it
63 memory and has the capacity to hold exactly one capability. This is 16
64 bytes on 32-bit architectures and 32 bytes on 64-bit architectures.
83 the original and a different guard (see
89 capability has the same badge and guard as the original.
94 capability similarly to \apifunc{seL4\_CNode\_Move}{cnode_move} and
101 one from the second specified slot to the first, and one from the
102 third to the second. The first and third specified slots may be the
118 any outstanding sends that use the same badge and object as the
128 \obj{CNode} specified by its \texttt{root}, \texttt{node\_index}, and
131 The \texttt{num\_objects} argument specifies the number of capabilities (and, hence, objects)
142 \autoref{ch:notifications}), \obj{Page}s (see \autoref{ch:vspace}) and
146 are Read, Write, Grant and GrantReply. Read, Write and Grant are orthogonal to
155 methods such as \apifunc{seL4\_CNode\_Mint}{cnode_mint} and
192 the various capability types, and how capability-derivation failures
234 exception to this scheme for \obj{Endpoint} and \obj{Notification} capabilities --- they support an
240 and supports one level of derived children like other capabilities.
243 \section{Deletion and Revocation}
246 Capabilities in seL4 can be deleted and revoked. Both methods
255 all remaining in-kernel references and preparing the memory for
267 found cnode, and then trying to delete the swapped capability
272 CSpace. Instead, it deletes the root CNode, and the branches of the
293 the revoke is destroyed during the revoke and the revoke does not
297 removed during the operation and the operation stops part way
298 through. Both these scenarios can be and should be avoided at
301 Note that for page tables and page directories
315 CSpaces are designed to permit sparsity, and the process of looking-up
321 objects, and each \obj{CNode} is a table of slots, where each slot can
348 (including nothing). If $s$ contains a \obj{CNode} capability~$c$ and
351 repeats, starting from the \obj{CNode} capability~$c$ and using these
360 all levels, various guard and radix sizes and internal CNode
369 \item a top level CNode object with a 12-bit guard set to 0x000 and
373 \item second level CNodes with different guards and slot counts;
379 where there are no bits remaining to be translated; and
386 of slots and the circular references within it.
396 and addressing a range of capability slots.
427 \item[Cap A.] The first CNode has a 4-bit guard set to 0x0, and an
434 \item[Cap B.] Again, the first CNode has a 4-bit guard set to 0x0, and
436 It also has a 4-bit guard of 0x0 and Cap B resides at index
442 of the second CNode. The third CNode has no guard and Cap C is at
448 of 0x00F00060 and a window size of 5.
461 the L2 and L3 CNode Caps are the same, but that their depth limits
468 slots, the user supplies a starting address and a window size.
478 indicates the type of lookup failure and the meaning of later words