+1 I don't really mind any of these names, except I don't like enhancements, which has the connotation of "a Jira issue we will never fix" for me. And a new feature is not necessarily an

That is good. (Note - since RFC will be readily accessible now, question of how much it should stay in sync with deviations during actual implementation/review would be a question to answer

Hi Anas, "Nashif, Anas" <anas.nashif(a)intel.com> writes: +1 Just for reference the Rust[1] project has a similar concept, and it's been working for some time, it may give a few

I also second "proposals".

NEW JIRA items within last 24 hours: 3 [ZEP-283] need to support development in subsystem branches https://jira.zephyrproject.org/browse/ZEP-283 [ZEP-281] nios2: TCF support

Of those three, I prefer 'proposals'. Enhancement doesn't feel appropriate when you add something entirely new, and blueprints could be better used for something involving board diagrams and the

Hi, We are looking for a better workflow and tools for making and maintaining enhancement proposals for Zephyr. Currently contributors and developers are asked to send an email to the mailing list

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/1852 : arc: Set __start entry point to be same as __reset - https://gerrit.zephyrproject.org/r/1855 : nanokernel: Introduce workqueue

Sounds good. I'll do this in the next iteration. One of us is certainly missing something, that's for sure. And it's likely me :) I was under the impression that nano_fifos did their own

Hi Vlad, Instead of storing and passing work_arg to the callback, did you consider passing just the nano_work struct itself and then using CONTAINER_OF() in the callback to get the context its part

Rework drivers that offer the possibility of using a system-wide workqueue to use the new API. In a second step, these drivers can be refactored to use their own workqueue instead of a homegrown

In the process, also rename CONFIG_SENSOR_DELAYED_WORK to something more meaningful and make it visible in menuconfig. Previously it was selected implicitly by drivers when needed, but this is error

Add a generic API for drivers to start workqueues and submit work items. This is needed by drivers which need to schedule code that might sleep from an ISR to run in fiber context. Change-Id:

Many drivers need to start fibers whose parameters are based on user configuration. Make it easier to specify such parameters by creating a fiber_config structure and a wrapper to use it. Change-Id:

Patches are also available on Gerrit: https://gerrit.zephyrproject.org/r/#/q/topic:workqueue This series introduces a generic way to schedule work that will be executed in fiber context. The

NEW JIRA items within last 24 hours: 32 [ZEP-266] nios2: implement linker script https://jira.zephyrproject.org/browse/ZEP-266 [ZEP-273] nios2: implement flashing scripts

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/1821 : microkernel: lock interrupts in _k_state_bit_[re]set() - https://gerrit.zephyrproject.org/r/1820 : drivers/nble: Pass

Hi, Zephyr v1.3.0 has been tagged. The merge window for the next release is now open.  Below is the list of changes since v1.3.0-rc2. Regards Javier B. Perez Anas Nashif

NEW JIRA items within last 24 hours: 4 [ZEP-245] Restructure Documentation content https://jira.zephyrproject.org/browse/ZEP-245 [ZEP-242] Collaboration Guidelines Restructure

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/1805 : drivers/nble: Implement notification for all conns - https://gerrit.zephyrproject.org/r/1804 : drivers/nble: Implement