The test granted access to the user work queue stack from the user
work thread; this was done by k_work_user_queue_start() so was
unnecessary. Document why it's ok to grant other access after the
work thread was started.
Fix a race condition where the non-work user thread might have started
before it was given access to the resources it needs.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The new API cannot be used from userspace because it is not merely a
wrapper around existing userspace-capable objects (threads and
queues), but instead requires much more complex and lower-level access
to memory that can't be touched from userspace. The vast majority of
work queue users are operating from privileged mode, so there's little
motivation to go through the pain and complexity of converting all
functions to system calls.
Copy the necessary pieces of the existing userspace work queue API out
and expose them with new names and types:
* k_work_handler_t becomes k_work_user_handler_t
* k_work becomes k_work_user
* k_work_q becomes k_work_user_q
etc. Because the replacement API cannot use the same types new API
names are also introduced to make it more clear that the userspace
work queue API is a separate functionality.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
This adds an app which utilizes common kernel functions as a
starting point to gauge kernel footprint.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
