OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/kernel/system_work_q.c

34 lines
643 B
C
Raw Normal View History

unified: dissociate system workqueue from common workqueue module Making a reference to the common work queue code should not necessarily drag in the system workqueue, since it is possible to use a workqueue that is not the system workqueue. This is done by moving the system workqueue into its own code module. Moving the system workqueue to its own code module allows removing the NANO_WORKQUEUE and SYSTEM_WORKQUEUE kconfig options, and compiling the common workqueue code and system workqueue all the time. They are only linked in the final image if a reference to them exist, same as the other kernel modules. Change-Id: I6f48d2542bda24f4702e7c2e317818dd082b3c11 Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2016-11-05 03:47:32 +08:00
/*
* Copyright (c) 2016 Wind River Systems, Inc.
* Copyright (c) 2016 Intel Corporation
*
license: Replace Apache boilerplate with SPDX tag Replace the existing Apache 2.0 boilerplate header with an SPDX tag throughout the zephyr code tree. This patch was generated via a script run over the master branch. Also updated doc/porting/application.rst that had a dependency on line numbers in a literal include. Manually updated subsys/logging/sys_log.c that had a malformed header in the original file. Also cleanup several cases that already had a SPDX tag and we either got a duplicate or missed updating. Jira: ZEP-1457 Change-Id: I6131a1d4ee0e58f5b938300c2d2fc77d2e69572c Signed-off-by: David B. Kinder <david.b.kinder@intel.com> Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2017-01-19 09:01:01 +08:00
* SPDX-License-Identifier: Apache-2.0
unified: dissociate system workqueue from common workqueue module Making a reference to the common work queue code should not necessarily drag in the system workqueue, since it is possible to use a workqueue that is not the system workqueue. This is done by moving the system workqueue into its own code module. Moving the system workqueue to its own code module allows removing the NANO_WORKQUEUE and SYSTEM_WORKQUEUE kconfig options, and compiling the common workqueue code and system workqueue all the time. They are only linked in the final image if a reference to them exist, same as the other kernel modules. Change-Id: I6f48d2542bda24f4702e7c2e317818dd082b3c11 Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2016-11-05 03:47:32 +08:00
*/
/**
* @file
*
* System workqueue.
*/
#include <kernel.h>
#include <init.h>
kernel: introduce stack definition macros The existing __stack decorator is not flexible enough for upcoming thread stack memory protection scenarios. Wrap the entire thing in a declaration macro abstraction instead, which can be implemented on a per-arch or per-SOC basis. Issue: ZEP-2185 Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-06-03 03:56:47 +08:00
K_THREAD_STACK_DEFINE(sys_work_q_stack, CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE);
unified: dissociate system workqueue from common workqueue module Making a reference to the common work queue code should not necessarily drag in the system workqueue, since it is possible to use a workqueue that is not the system workqueue. This is done by moving the system workqueue into its own code module. Moving the system workqueue to its own code module allows removing the NANO_WORKQUEUE and SYSTEM_WORKQUEUE kconfig options, and compiling the common workqueue code and system workqueue all the time. They are only linked in the final image if a reference to them exist, same as the other kernel modules. Change-Id: I6f48d2542bda24f4702e7c2e317818dd082b3c11 Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2016-11-05 03:47:32 +08:00
struct k_work_q k_sys_work_q;
static int k_sys_work_q_init(struct device *dev)
{
ARG_UNUSED(dev);
k_work_q_start(&k_sys_work_q,
sys_work_q_stack,
kernel: introduce stack definition macros The existing __stack decorator is not flexible enough for upcoming thread stack memory protection scenarios. Wrap the entire thing in a declaration macro abstraction instead, which can be implemented on a per-arch or per-SOC basis. Issue: ZEP-2185 Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2017-06-03 03:56:47 +08:00
K_THREAD_STACK_SIZEOF(sys_work_q_stack),
unified: dissociate system workqueue from common workqueue module Making a reference to the common work queue code should not necessarily drag in the system workqueue, since it is possible to use a workqueue that is not the system workqueue. This is done by moving the system workqueue into its own code module. Moving the system workqueue to its own code module allows removing the NANO_WORKQUEUE and SYSTEM_WORKQUEUE kconfig options, and compiling the common workqueue code and system workqueue all the time. They are only linked in the final image if a reference to them exist, same as the other kernel modules. Change-Id: I6f48d2542bda24f4702e7c2e317818dd082b3c11 Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2016-11-05 03:47:32 +08:00
CONFIG_SYSTEM_WORKQUEUE_PRIORITY);
return 0;
}
kernel: initialize system work queue after kernel is up The system work queue spawns a coop thread to hanlde the work items. If it is spawned before the kernel is up and the initialization dummy thread's priority is lower, there will be a context switch into the system work queue's thread at that time, before the kernel is ready to handle this. Change-Id: I879659ab58231c5a5cfaa34f2f65c2eccab99142 Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2016-12-17 07:01:13 +08:00
SYS_INIT(k_sys_work_q_init, POST_KERNEL, CONFIG_KERNEL_INIT_PRIORITY_DEFAULT);