Lines Matching full:object
6 A kernel object can be one of three classes of data:
8 * A core kernel object, such as a semaphore, thread, pipe, etc.
25 a kernel object, checks are performed by system call handler functions
26 that the kernel object address is valid and that the calling thread
29 Permission on an object also has the semantics of a reference to an object.
30 This is significant for certain object APIs which do temporary allocations,
33 If an object loses all references, two events may happen:
35 * If the object has an associated cleanup function, the cleanup function
36 may be called to release any runtime-allocated buffers the object was using.
38 * If the object itself was dynamically allocated, the memory for the object
41 Object Placement
49 In order for a static kernel object to be usable by a user thread via system
50 call APIs, several conditions must be met on how the kernel object is declared:
52 * The object must be declared as a top-level global at build time, such that it
56 in a special table of kernel object metadata. Kernel objects may be members
62 * Any memory reserved for a kernel object must be used exclusively for that
63 object. Kernel objects may not be members of a union data type.
66 included in the generated table that is used to validate kernel object pointers
70 debugging why some object was unexpectedly not being tracked. This
79 :c:func:`k_object_alloc` API may be used to instantiate an object from
84 object to be released.
86 * If an object's references drop to zero (which happens when no threads have
87 permissions on it) the object will be automatically freed. User threads
88 may drop their own permission on an object with
102 valid kernel object instances in the binary. It accomplishes this by parsing
106 the object placement criteria will have their memory addresses placed in a
109 of what may or may not be a valid kernel object, the address can be validated
114 incorrect operations, such as calling a UART API on a sensor driver object, can
118 The table itself maps kernel object memory addresses to instances of
119 :c:struct:`z_object`, which has all the metadata for that object. This
122 * A bitfield indicating permissions on that object. All threads have a
124 bitfield for an object to see if that thread has permission on it. The size
127 * A type field indicating what kind of object this is, which is some
129 * A set of flags for that object. This is currently used to track
130 initialization state and whether an object is public or not.
131 * An extra data field. The semantics of this field vary by object type, see
135 which is used in parallel to the gperf table when validating object pointers.
140 Supervisor threads can access any kernel object. However, permissions for
149 same permissions as the parent thread, except the parent thread object.
155 on its own thread object. Other kernel objects by default are not usable.
161 thread object.
163 * A thread that has permission on an object, or is running in supervisor mode,
164 may grant permission on that object to another thread via the
169 permission, or the object whose access is being granted, do not need to be
171 have permissions on both the kernel object and the target thread object.
173 * Supervisor threads may declare a particular kernel object to be a public
174 object, usable by all current and future threads with the
176 untrusted or exploited code will then be able to access the object. Use
183 Once a thread has been granted access to an object, such access may be
187 object.
194 permission on the allocated object to the calling thread.
199 Most operations on kernel objects will fail if the object is considered to be
200 in an uninitialized state. The appropriate init function for the object must
212 If a kernel object is initialized with a private static initializer, the object
214 thread, otherwise the kernel will consider the object uninitialized if accessed
235 Creating New Kernel Object Types
239 to define some new kernel object types. There are different steps needed