Lines Matching full:may
18 with addresses to kernel objects when making API calls, but may never
23 Since user threads may not directly manipulate kernel objects, all use of
33 If an object loses all references, two events may happen:
36 may be called to release any runtime-allocated buffers the object was using.
56 in a special table of kernel object metadata. Kernel objects may be members
63 object. Kernel objects may not be members of a union data type.
69 The debug output of the :ref:`gen_kobject_list.py` script may be useful when
77 Kernel objects may also be allocated at runtime if
79 :c:func:`k_object_alloc` API may be used to instantiate an object from
80 the calling thread's resource pool. Such allocations may be freed in two
83 * Supervisor threads may call :c:func:`k_object_free` to force a dynamic
88 may drop their own permission on an object with
90 cleared when a thread terminates. Supervisor threads may additionally
109 of what may or may not be a valid kernel object, the address can be validated
164 may grant permission on that object to another thread via the
166 :c:func:`k_thread_access_grant` may also be used, which accepts an arbitrary
173 * Supervisor threads may declare a particular kernel object to be a public
180 then the :c:macro:`K_THREAD_ACCESS_GRANT()` may be used to grant that thread
183 Once a thread has been granted access to an object, such access may be
185 available to user threads, however user threads may use
238 When implementing new kernel features or driver subsystems, it may be necessary