diff --git a/doc/api18970.md b/doc/api18970.md
new file mode 100644
index 00000000000000..767c50eba3c254
--- /dev/null
+++ b/doc/api18970.md
@@ -0,0 +1,571 @@
+# Draft material to review in support of [#18970][]
+
+[//]: # (cmark-gfm -e table -e footnotes doc/api18970.md > /tmp/api18970.html)
+
+[#18970]: https://github.com/zephyrproject-rtos/zephyr/issues/18970
+
+Note: See the Background section below for technical concepts necessary
+to understand the definitions.
+
+## API Attributes
+
+This work is leading to a proposal for specific attributes for API
+behavior that should be documented in function descriptions and, in some
+cases, exposed through API at runtime.
+
+* **reschedule** if executing the function reaches a reschedule point
+* **sleep** if executing the function can cause the invoking thread to
+  sleep
+* **no-wait** if a parameter to the function can prevent the invoking
+  thread from trying to sleep
+* **isr-ok** if the function can always be safely called from non-thread
+  (interrupt) context even if it may return an error in that case
+* **pre-kernel-ok** if the function can be safely called before the
+  kernel has been fully initialized, even if it may return an error in
+  that case
+* **async** if the function may return before the operation it
+  initializes is complete (i.e. function return and operation completion
+  are asynchronous)
+* **supervisor** if the calling thread must have supervisor privileges
+  to execute the function
+
+Details on the behavioral impact of each attribute are in the following
+sections.  Attributes for some common kernel API are below:
+
+name                   | reschedule | sleep | no-wait | isr-ok | async | supervisor
+---------------------- | ---------- | ----- | ------- | ------ | ----- | ----------
+`k_busy_wait`          | no         | no*   | no*     | yes*   | no    | no
+`k_sem_give`           | yes        | no    | no*     | yes*   | no    | no
+`k_sleep`              | yes*       | yes   | no      | no     | no    | no
+`k_sem_take`           | yes*       | yes   | yes     | no     | no    | no
+`k_thread_create`      | ?          | ?     | ?       | ?      | no    | yes
+`spi_transceive`       | yes*       | yes   | no      | no     | no    | no
+`spi_transceive_async` | yes*       | yes   | no      | no     | yes   | no
+
+`*` indicates the attribute value is implicit from another attribute.
+For example a function that is not **reschedule** cannot be **sleep**;
+one that **sleeps** is necessarily **reschedule**; and one that cannot
+sleep has no use for no-wait support and is implicitly **isr-ok**.
+
+### reschedule
+
+The reschedule attribute is used on a function that can reach a
+reschedule point within its execution.
+
+#### Commentary
+
+The significance of this attribute is that when a rescheduling function is
+invoked by a thread it is possible for that thread to be suspended as a
+consequence of a higher-priority thread being made ready.  Whether the
+suspension actually occurs depends on the operation associated with the
+reschedule point and the relative priorities of the invoking thread and
+the head of the ready queue.
+
+Note that in the case of timeslicing, or reschedule points executed from
+interrupts, any thread may be suspended in any function.
+
+Functions that are not **reschedule** may be invoked from either thread
+or interrupt context.
+
+Functions that are **reschedule** may be invoked from thread context.
+
+Functions that are **reschedule** but not **sleep** may be invoked from
+interrupt context.
+
+### sleep
+
+The sleep attribute is used on a function that can cause the invoking
+thread to sleep.
+
+Functions that are **sleep** are implicitly **reschedule**.
+
+Functions that are **sleep** may be invoked from thread context.
+
+Functions that are **sleep** may be invoked from interrupt context if
+and only if invoked in **no-wait** mode.
+
+#### Commentary
+
+This attribute is of relevance specifically when considering
+applications that use only non-preemptible threads, because the
+kernel will not replace a running cooperative-only thread at a reschedule
+point unless that thread has explicitly invoked an operation that caused
+it to sleep.
+
+Note that this attribute does not imply the function will sleep
+unconditionally, but that the state of the system may require the
+invoking thread to suspend, wait, or invoke `k_yield()` before it can
+complete its operation.  This behavior may be mediated by **no-wait**.
+
+### no-wait
+
+The no-wait attribute is used on a function to indicate that a parameter
+to the function can force an execution path that will not cause the
+invoking thread to sleep.
+
+Functions with this attribute may be invoked from interrupt context when
+the parameter selects the no-wait path.
+
+Functions that are **no-wait** functions are implicitly **sleep**.
+
+#### Commentary
+
+The paradigmatic case of a no-wait function is a function that takes a
+timeout, to which `K_NO_WAIT` can be passed.  The semantics of this
+special timeout value are to execute the function's operation as long as
+it can be completed immediately, and to return an error code rather than
+sleep if it cannot.
+
+It is use of the no-wait feature that allows functions like
+`k_sem_take()` to be invoked from ISRs, since it is not permitted to
+sleep in interrupt context.
+
+**NOTE** That a function has a no-wait path does not imply that taking
+that path guarantees the function is synchronous.
+
+### isr-ok
+
+The isr-ok attribute is used on a function to indicate that it can be
+called from interrupt context.  If necessary the function will use
+`k_is_in_isr()` to detect its calling context and force an execution
+path that will not cause the invoking thread to sleep.
+
+This attribute is intended for **sleep** functions that may be
+indirectly invoked from interrupt context with arguments that could
+attempt to put the invoking thread to sleep, e.g. because the function
+is not **no-wait** or the parameters do not select the no-wait path.
+
+Functions that are **isr-ok** may be always be safely invoked from
+interrupt context, and will return an error if they were unable to
+fulfill their behavior in that context.
+
+### pre-kernel-ok
+
+The pre-kernel-ok attribute is used on a function to indicate that it
+will take reasonable steps to ensure it is safe to invoke before all
+kernel services are started. In some cases the invocation in that
+context may return an error code.
+
+#### Commentary
+
+This attribute is similar to **isr-ok** in function, but is intended
+for use by API that is expected to be called in `DEVICE_*INIT()`
+or `SYS_INIT()` calls that may be invoked with `PRE_KERNEL_1` or
+`PRE_KERNEL_2` initialization levels.
+
+Generally a function that is pre-kernel-ok checks `k_is_pre_kernel()`
+when determining whether it can fulfill its required behavior.  In many
+cases it would also check `k_is_in_isr()` so it can be isr-ok as well.
+
+### async
+
+A function is async (i.e. asynchronous) if it may return before the
+operation it initiates has completed.  An asynchronous function will
+generally provide a mechanism by which operation completion is reported,
+e.g. a callback or event.
+
+#### Commentary
+
+Note that asynchronous is orthogonal to context-switching.  Some API may
+provide completion information through a callback, but may suspend while
+waiting for the resource necessary to initiate the operation; an example
+is `spi_transceive_async()`.
+
+If a function is both **no-wait** and **async** then selecting the
+no-wait path only guarantees that the function will not sleep.  It does
+not affect whether the operation will be completed before the function
+returns.
+
+### supervisor
+
+The supervisor attribute is relevant only in user-mode applications, and
+indicates that the function cannot be invoked from user mode.
+
+## Background
+
+This section summarizes existing and relevant Zephyr concepts,
+introducing clarifications where necessary.  See also the Zephyr
+[glossary][].
+
+[glossary]: https://docs.zephyrproject.org/latest/glossary.html
+
+### Thread Terminology
+
+Thread behavior in Zephyr is documented in three locations which in
+aggregate are not entirely consistent:
+* [Threads](https://docs.zephyrproject.org/latest/reference/kernel/threads/index.html)
+* [Scheduling](https://docs.zephyrproject.org/latest/reference/kernel/scheduling/index.html)
+* The [Interrupt](https://docs.zephyrproject.org/latest/guides/porting/arch.html#interrupt-and-exception-handling)
+  and [Context Switching](https://docs.zephyrproject.org/latest/guides/porting/arch.html#thread-context-switching)
+  sections of the [Architecture Porting Guide](https://docs.zephyrproject.org/latest/guides/porting/arch.html)
+
+Zephyr defines [six thread
+states](https://docs.zephyrproject.org/latest/reference/kernel/threads/index.html#thread-states)
+of which four are active:
+
+* **Ready** when there is nothing that prevents the thread from becoming
+  active as the current thread, but it is not the current thread.
+* **Running** when the thread is active as the current thread (on a
+  processor).
+* **Waiting** when the thread is on a queue waiting for an event to occur
+  that will transition it to *Ready*.
+* **Suspended** when the thread is inactive and must be transitioned to
+  *Ready* explicitly (e.g. via `k_thread_resume()`.
+
+A thread is made **unready** if it transitions to *Suspended*,
+*Waiting*, or *Terminated*, whether the transition is a result of an
+action taken by the thread (e.g. `k_sleep()`) or an action initiated
+externally (e.g. `k_thread_abort()`).
+
+Zephyr defines [two mechanisms for selecting the running
+thread](https://docs.zephyrproject.org/latest/reference/kernel/scheduling/index.html#scheduling):
+* In **cooperative** scheduling a thread transitions from *Running* only
+  when it invokes `k_yield()`, or it (or something outside the current
+  thread) invokes an operation that makes the thread unready.
+* In **preemptive** scheduling a thread may be involuntarily
+  transitioned from *Running* to *Ready* based on a change in
+  conditions, such as elapsed runtime or transition of a higher-priority
+  thread to a *Ready* state.
+
+A **reschedule point** is any point where the kernel calls the internal
+logic that selects the next thread to run.  Reschedule points include:
+* Return from an ISR to thread execution;
+* Invoking `k_yield()`;
+* Invoking any action that makes the current thread unready;
+* Most (all?) actions that cause a thread to become *Ready*, including
+  completion of a timeslice when a preemptible thread is current.
+
+A **context switch** occurs at a reschedule point when the next thread
+selected to run is different from the most recent current thread.
+
+Invoking a function that reaches a reschedule point does not guarantee a
+context switch, it simply provides an opportunity.  Whether a context
+switch occurs depends on the priority of the current thread and the
+thread at the head of the ready queue.
+
+Zephyr defines [two core classes of
+threads](https://docs.zephyrproject.org/latest/reference/kernel/threads/index.html#thread-priorities)
+with one [extension](https://docs.zephyrproject.org/latest/reference/kernel/scheduling/index.html#meta-irq-priorities):
+
+* **preemptible** threads remain the current thread until
+  * a cooperative thread becomes *Ready*; or
+  * a higher-priority preemptible thread becomes *Ready*; or
+  * the thread invokes an operation that explicitly causes it to become
+    unready.
+* **cooperative** threads remain the current thread until something
+  causes it to become unready or it invokes `k_yield()`.
+* **meta-irq** threads are cooperative threads with a special property
+  that they *do* pre-empt cooperative threads with lower priorites,
+  *and* are not excluded when using a scheduler lock.
+
+The class of the thread is uniquely determined by its priority: All
+cooperative threads have a priority higher than any preemptible thread,
+and meta-IRQ threads have a priority higher than any other cooperative thread.
+
+Most Zephyr threads are cooperative, and some code may take advantage of
+this by assuming the behavior of reschedule points reached during an
+operation will be guided by the invoking thread being cooperative.
+
+Given this, define the following terms:
+
+* A thread **suspends** when it voluntarily invokes a function that
+  causes it to transition from *Running* to *Suspended*.
+  (`k_sleep()` is such a function.)
+* A thread **waits** when it voluntarily invokes a function that causes
+  it to transition from *Running* to *Waiting*.  (`k_poll()` is such a
+  function.)
+* A thread **yields** when it voluntarily invokes a function that causes
+  it to transition from *Running* to *Ready*.  (`k_yield()` is such a
+  function.)
+* A thread **sleeps** when it voluntarily invokes a function that causes
+  it to suspend, wait, or yield.
+* A thread is **preempted** when it is *Running* but a reschedule point
+  (involuntarily) transitions it to *Ready*.
+
+A **context switch** occurs when the reschedule point selects a thread
+other than the current thread to execute next.
+
+#### Digresssions and random notes
+
+*Suspended* could be perceived as a variant of *Waiting* where the
+releasing event is an invocation of `k_thread_resume()`, possibly
+performed by the callback of a timeout associated with the thread.
+
+For operations that cause a transition from *Running* to *Waiting* a
+timeout value `K_NO_WAIT` indicates that the operation should fail
+rather than change the thread state.  The failure is indicated with an
+operation-specific error code such as `-EAGAIN`, `-EBUSY`, `-ENOMEM`,
+and `-ENOMSG`.
+
+* `z_pend_curr` transitions the current thread to **Waiting**;
+* `k_yield` transitions the current thread to **Ready** and moves it to
+  the end of the ready queue.  It also explicitly overrides the default
+  preservation of cooperative threads as the current thread.
+* `k_sleep` invokes `k_yield()` if timeout is zero, otherwise suspends
+  the thread until the timeout.
+
+An operation cannot be invoked from an ISR if:
+* It transitions the current thread to *Suspended* (per assert in
+  `z_tick_sleep()`)
+* It transitions the current thread to *Waiting* (per documentation of
+  e.g. `k_sem_take()`)
+* It transitions the current thread to *Ready* (per assert in
+  `k_yield()`)
+
+Generalizing this, and consistent with the informal answer to issue
+21341, an operation cannot be invoked when invoked from a non-thread
+context (interrupt or pre-kernel) if it could cause its invoking thread
+to sleep, because without in invoking thread it cannot implement the
+required behavior.
+
+### Context Terminology
+
+There are three execution contexts in which code might be executed,
+shown in the following table.
+
+Context    | Stack     | Kernel Services | Indicator
+---------- | --------- | --------------- | ----------
+pre-kernel | interrupt | some available  | `k_is_pre_kernel()`
+thread     | thread    | available       | `!(k_is_pre_kernel() \|\| k_is_in_isr())`
+interrupt  | interrupt | some available  | `k_is_in_isr()`
+
+Kernel services are available in pre-kernel and interrupt context only
+when their behavior does not allow the caller to sleep.  Services for
+which state is not yet initialized are also excluded (this mostly
+applies to pre-kernel context).
+
+**TODO** fill in gaps above where content below is not addressed
+
+This section is intended to describe the privilege and processor context
+variations in which a thread can run.  It should provide or reference
+definitions of terms like this:
+
+* Kernel [initialization
+  level](https://docs.zephyrproject.org/latest/reference/drivers/index.html#initialization-levels)
+* User-space versus kernel (system call)
+* Normal ("thread"?) versus interrupt (invoked from an Interrupt Service
+  Routine)
+
+For API behavior we are interested in whether a particular function
+**may**, **must**, or **must not** be invoked from a specific context.
+
+### Function vs Operation
+
+tl;dr: A function *returns* while an operation *completes*.
+
+A **function** is an addressible sequence of actions to which control is
+transferred by **invoking** (calling) the function with various
+parameters, and from which control is transferred back to the point and
+context where it was invoked when the function **returns**.
+
+A function may succeed or fail.  In many cases failure is indicated by a
+negative integer return value while success is indicated by a
+non-negative integer return value, but specific functions may use other
+conventions.
+
+An **operation** is behavior, which is generally initiated by invoking a
+function.  An operation can also succeed or fail.  An operation
+**completes** when the success or failure of the operation has been
+determined and made available through whatever mechanism was specified
+through the initiating function.
+
+For APIs we are particularly interested in the relationship between the
+function and its associated operation.  Some potential relationships
+include:
+* The function succeeds if and only if its associated operation
+  completes with success. (This is usually expected of *synchronous*
+  functions.)
+* If the function fails then its associated operation has not been
+  initiated.  If the function succeeds then its associated operation has
+  been initiated.  The success or failure of the operation is not
+  otherwise coupled to success or failure of its initiating function.
+  (This is usually expected of *asynchronous* functions.)
+
+## Outdated Definitions
+
+These may be helpful in clarifying some of the terms in the API
+Attributes section.  They include terms for API behavior that, at this
+time, do not seem worth recording as attributes.
+
+### rescheduling (function)
+
+A function is rescheduling when a path through it reaches a reschedule
+point.
+
+#### Commentary
+
+Note that whether a rescheduling function will cause a context switch
+depends on the priority of the current and first ready threads at the
+reschedule point and whether the reschedule point enabled unconditional
+preemption.
+
+Unless interrupts are disabled a cooperative thread may be
+context-switched in any function if the interrupt causes a meta-irq
+thread to become ready, regardless of whether the function is
+rescheduling.
+
+If interrupts are disabled a zero-latency interrupt can still be
+invoked, which may cause a meta-irq thread to become ready.
+
+The term *rescheduling* applies only to functions that (directly or
+indirectly) invoke operations that (may) encounter a reschedule point.
+I.e. any resulting context switch is a result of invoking the function,
+rather than some external behavior.
+
+### sleeps (thread)
+
+A thread sleeps if it is the current thread and it invokes an operation
+that directly causes itself to transition to an active state other than
+*Running*.
+
+#### Commentary
+
+When the current thread sleeps the reschedule point will context-switch
+unless the current thread remains *Ready* and is at the head of the
+ready queue.
+
+A rescheduling function like `k_mutex_unlock()` does not directly cause
+a thread to sleep.  The calling thread may sleep indirectly because
+`k_mutex_unlock()` made a higher-priority pre-empting thread ready.
+
+### blocking (function)
+
+A function is blocking if it can cause its invoking thread to sleep.
+
+#### Commentary
+
+**TODO** It would be best to eliminate this term and define things in
+terms of "does not sleep".  For now this is convenient shorthand.
+
+### no-wait (function)
+
+A function is no-wait if it is not blocking.
+
+A function is conditionally no-wait if it is blocking but a parameter
+can force the function to take a path that will not reach a blocking
+reschedule point.
+
+### isr-callable (function)
+
+A function is isr-callable if and only if it is (conditionally) no-wait.
+
+#### Commentary
+
+META: This is intentionally not `isr-safe` because experience suggests
+people may confuse it with "interrupt-safe", which is completely
+different.
+
+### thread-safe
+
+A function is thread-safe if its behavior is correct when invocations
+from multiple threads are active simultaneously.
+
+#### Commentary
+
+See *rescheduling*.
+
+Note that it may be impossible to guarantee thread safety when using
+Zephyr preemptible or meta-irq threads.
+
+### reentrant
+
+A function is reentrant if its behavior is correct when it is invoked by
+(indirect) recursion from the same thread.
+
+### interrupt-safe
+
+A function is interrupt-safe if its behavior is not affected by
+concurrent access to shared data from interrupts.
+
+#### Commentary
+
+Most public API will satisfy this condition; some private API may not.
+
+We need to be able to say succinctly "Unless otherwise specified all API
+functions are interrupt-safe" and expect people to know what that means.
+A specific example would be the GPIO API.  Because GPIO write functions
+may be invoked from ISRs read-modify-write code like:
+
+```
+u32_t out = gpio->OUT;
+gpio->OUT ^= (out & ~mask) | (value & mask);
+```
+
+*must* be wrapped in a spin-lock to be interrupt-safe.  Many current
+implementations do not satisfy this requirement.
+
+On the other hand internal functions may be written to assume they are
+called with interrupts disabled, or a specific lock held.
+
+**TODO** standard marking?
+
+### atomic
+
+An operation is atomic if the steps it makes internally cannot be
+affected by nor visible to interleaving executions, such as from
+interrupts or thread pre-emption.
+
+#### Commentary
+
+An operation that is atomic is by definition interrupt-safe.
+
+An operation that is atomic is by definition thread-safe.
+
+### synchronous (function) (vs asynchronous)
+
+A function is synchronous if it will not return until the operation it
+initiates has completed.
+
+#### Commentary
+
+The term "blocking" may be used for a synchronous function in cases
+where synchrony is produced by causing the invoking thread to sleep.  It
+is possible to have a synchronous non-sleeping function; an example is
+`k_busy_wait()`.
+
+It is also possible to have an asynchronous sleeping function; an
+example is `spi_transceive_async()`.
+
+### asynchronous (function) (vs synchronous)
+
+A function is asynchronous if it may return before the operation it
+initiates has completed.  An asynchronous function will generally
+provide a mechanism by which operation completion is reported, e.g. a
+callback or event.
+
+#### Commentary
+
+Note that asynchronous is orthogonal to context-switching.  Some API may
+provide completion information through a callback, but may suspend while
+waiting for the resource necessary to initiate the operation; an example
+is `spi_transceive_async()`.
+
+### queued (proposed, TBD)
+
+A function is queued if it is asynchronous and allows multiple
+operations to be outstanding at any time.
+
+#### Commentary
+
+This concept is proposed due to operations like `spi_transceive_async()`
+which returns its result through a signal but will suspend if the device
+is already processing an asynchronous operation.
+
+A related capability that is non-suspendable could be implemented
+through through passing a chainable persisted state object to hold the
+operation parameters in a persisted state object that can be added to an
+internal queue for processing when the required resource is available.
+Such a theoretical API might be described as *queued*.
+
+Since this term specifies the mechanism by which a non-suspending
+asynchronous function supports multiple incomplete operations, rather
+than just that behavior, it should probably be avoided.
+
+## Other Rules
+
+## To Do
+
+- [ ] Consider a standard marking for private functions that must be
+      invoked with an held or interrupts disabled, such as a suffix
+      `_locked`.
+- [ ] Define the terminology related to execution context
diff --git a/zephyr-api.csv b/zephyr-api.csv
new file mode 100644
index 00000000000000..6145d8e237780f
--- /dev/null
+++ b/zephyr-api.csv
@@ -0,0 +1,167 @@
+Name,Type,21389,Attributes
+k_object_access_grant,s,
+k_object_access_revoke,,
+k_object_release,s,
+k_object_access_all_grant,,
+k_object_alloc,s,
+k_object_free,,
+k_obj_free,,
+k_thread_foreach,,Threads
+k_thread_create,s,Supervisor
+k_thread_user_mode_enter,,Supervisor
+k_thread_access_grant,m,
+k_thread_resource_pool_assign,,Threads
+k_thread_system_pool_assign,,Threads
+k_sleep,s,Threads,sleep
+k_usleep,s,Threads,sleep
+k_busy_wait,s,Threads,-
+k_yield,s,Threads,sleep
+k_wakeup,s,,reschedule
+k_current_get,s,
+k_thread_abort,s,
+k_thread_start,s,
+k_thread_priority_get,s,
+k_thread_priority_set,s,Threads
+k_thread_deadline_set,s,
+k_thread_cpu_mask_clear,,
+k_thread_cpu_mask_enable_all,,
+k_thread_cpu_mask_enable,,
+k_thread_cpu_mask_disable,,
+k_thread_suspend,s,,reschedule;sleep if curr;
+k_thread_resume,s,,reschedule
+k_sched_time_slice_set,,
+k_is_in_isr,,Threads;ISRs,-
+k_is_pre_kernel,,,-
+k_is_preempt_thread,s,Threads;ISRs
+k_sched_lock,,
+k_sched_unlock,,Threads
+k_thread_custom_data_set,s,
+k_thread_custom_data_get,s,
+k_thread_name_set,s,
+k_thread_name_get,s,
+k_thread_name_copy,s,
+k_thread_state_str,,
+k_timer_init,,
+k_timer_start,s,
+k_timer_stop,s,Threads;ISRs
+k_timer_status_get,s,
+k_timer_status_sync,s,Threads
+k_timer_remaining_get,s,
+k_timer_user_data_set,s,
+k_timer_user_data_get,s,
+k_uptime_get,s,
+k_uptime_get_32,,
+k_uptime_delta,,
+k_uptime_delta_32,,
+k_cycle_get_32,,
+k_queue_init,s,
+k_queue_cancel_wait,s,Threads;ISRs
+k_queue_append,,Threads;ISRs
+k_queue_alloc_append,s,Threads;ISRs
+k_queue_prepend,,Threads;ISRs
+k_queue_alloc_prepend,s,Threads;ISRs
+k_queue_insert,,Threads;ISRs
+k_queue_append_list,,Threads;ISRs
+k_queue_merge_slist,,Threads;ISRs
+k_queue_get,s,Threads;ISRs
+k_queue_remove,,Threads;ISRs
+k_queue_unique_append,,Threads;ISRs
+k_queue_is_empty,s,Threads;ISRs
+k_queue_peek_head,s,
+k_queue_peek_tail,s,
+k_futex_wait,s,
+k_futex_wake,s,
+k_fifo_init,m,
+k_fifo_cancel_wait,m,Threads;ISRs
+k_fifo_put,,Threads;ISRs
+k_fifo_alloc_put,m,Threads;ISRs
+k_fifo_put_list,m,Threads;ISRs
+k_fifo_put_slist,m,Threads;ISRs
+k_fifo_get,m,Threads;ISRs
+k_fifo_is_empty,m,Threads;ISRs
+k_fifo_peek_head,m,
+k_fifo_peek_tail,m,
+k_lifo_init,m,
+k_lifo_put,m,Threads;ISRs
+k_lifo_alloc_put,m,Threads;ISRs
+k_lifo_get,m,Threads;ISRs
+k_stack_init,,
+k_stack_alloc_init,s,
+k_stack_cleanup,,
+k_stack_push,s,Threads;ISRs
+k_stack_pop,s,Threads;ISRs
+k_work_init,,
+k_work_submit_to_queue,,Threads;ISRs
+k_work_submit_to_user_queue,,Threads;ISRs
+k_work_pending,,Threads;ISRs
+k_work_q_start,,
+k_work_q_user_start,,User mode
+k_delayed_work_init,,
+k_delayed_work_submit_to_queue,,Threads;ISRs
+k_delayed_work_cancel,,Threads;ISRs
+k_work_submit,,Threads;ISRs
+k_delayed_work_submit,,Threads;ISRs
+k_delayed_work_remaining_get,,
+k_work_poll_init,,
+k_work_poll_submit_to_queue,,Threads;ISRs
+k_work_poll_submit,,Threads;ISRs
+k_work_poll_cancel,,Threads;ISRs
+k_mutex_init,s,
+k_mutex_lock,s,,sleep;no-wait
+k_mutex_unlock,s,,reschedule
+k_sem_init,s,
+k_sem_take,s,Threads;ISRs,sleep;no-wait
+k_sem_give,s,Threads;ISRs,reschedule
+k_sem_reset,s,
+k_sem_count_get,s,
+k_msgq_init,,
+k_msgq_alloc_init,s,
+k_msgq_cleanup,,
+k_msgq_put,s,Threads;ISRs
+k_msgq_get,s,Threads;ISRs
+k_msgq_peek,s,Threads;ISRs
+k_msgq_purge,s,
+k_msgq_num_free_get,s,
+k_msgq_get_attrs,s,
+k_msgq_num_used_get,s,
+k_mbox_init,,
+k_mbox_put,,
+k_mbox_async_put,,
+k_mbox_get,,
+k_mbox_data_get,,
+k_mbox_data_block_get,,
+k_pipe_init,,
+k_pipe_cleanup,,
+k_pipe_alloc_init,s,
+k_pipe_put,s,
+k_pipe_get,s,
+k_pipe_block_put,,
+k_mem_slab_init,,
+k_mem_slab_alloc,,
+k_mem_slab_free,,
+k_mem_slab_num_used_get,,
+k_mem_slab_num_free_get,,
+k_mem_pool_alloc,,Threads;ISRs
+k_mem_pool_malloc,,
+k_mem_pool_free,,
+k_mem_pool_free_id,,
+k_malloc,,
+k_free,,
+k_calloc,,
+k_poll_event_init,,
+k_poll,s,Threads
+k_poll_signal_init,s,
+k_poll_signal_reset,s,
+k_poll_signal_raise,s,
+k_cpu_idle,,
+k_cpu_atomic_idle,,
+k_oops,,Threads;ISRs
+k_panic,m,
+k_mem_domain_init,,Supervisor
+k_mem_domain_destroy,,
+k_mem_domain_add_partition,,Supervisor
+k_mem_domain_remove_partition,,Supervisor
+k_mem_domain_add_thread,,Supervisor
+k_mem_domain_remove_thread,,Supervisor
+k_str_out,s,
+k_float_disable,s,