Date   

QEMU networking problem - has anyone ever run into this problem?

Immo Birnbaum
 

Hi all,

I'm having a bit of an issue when it comes to exchanging network packets with QEMU via the TAP interface "zeth" as set up by net-setup.sh.

When building the TCP socket echo server demo for the qemu_x86 target with the e1000 driver enabled within Zephyr and -nic tap,model=e1000 passed to QEMU (Ethernet mode, SLIP driver disabled), the TAP interface works as expected while QEMU is running. When building the same application for the qemu_cortex_r5 target (which simulates the UltraScale RPU on the Xilinx ZCU102 board) using my Xilinx GEM network driver, in this case the QEMU networking parameter is -nic tap,model=cadence_gem, there's an odd effect I can't really make any sense of. When I ping the IP address used by Zephyr, an ARP request is sent, an ARP reply is received, "arp -i zeth" on the host side shows the correct MAC/IP tuple. These packets show up in Wireshark which is running at the same time acquiring all traffic on the zeth interface.

Afterwards, the ICMP echo request is sent by the Linux host, Zephyr receives it and generates a reply (visible both as hexdump on the Zephyr console and within Wireshark). As more requests and replies are sent, the seq number in the ICMP packets increases, each reply packet's seq matches that of the previous request. Yet, the ping command on the Linux host doesn't receive this data. The output generated by ping is always "x packets transmitted, 0 received, 100% loss". Yet, when calling ifconfig, a non-zero packet count is shown for both RX and TX, and those numbers match the packets logged by Wireshark. Ifconfig also shows that for both RX and TX, there were no errors, no overruns, no packets dropped and no collisions. The same phenomenon can be observed when trying to connect to the port opened by the echo server using PUTTY: the SYN packet is sent by the host, Zephyr generates the SYN/ACK reply, again visible in Wireshark, the calling application doesn't receive the data and sends another SYN packet multiple times, to which Zephyr replies with RST/ACK each time. PUTTY eventually indicates a timeout.

I'm at a loss as to why all packets are visible within Wireshark, so therefore, the zeth interface seems to work as expected, but the data in the Zephyr->host direction isn't handed over to the calling application, which works fine on the x86 target. I eventually suspected a bug within QEMU itself and built the latest version (both from the main repo and the Xilinx branch) from source, unfortunately, this didn't solve the problem. Has anyone ever observed this problem before when running a networking-enabled Zephyr application within QEMU?


Max Possible BLE communication range with Zephyr's 'hci_uart' app on nrf52840 chip #hci #nrf52480 #uart #ble #bluetooth

Mayank
 

Hello Community,
 
We are using nordic's nrf52840_pca10056 chip on our custom board and on top of that zephyr's 'hci_uart' application is running. (Zephyr version v2.1.0).On our custom board, the host side(i.MX6ull) we are using Linux kernel (v4.19) and integrated Bluez's stack (v5.50) with it.
 
Zephyr's application gives access to the 'hci0' interface at the host side and We are able to scan nearby BLE device and beacon using BLUEZ test utility. Currently, we are performing the connection stability test with different range and for that we are trying to make a connection to BLE devices, Let's say connecting to the Nordic's nrf52840 dev kit which is flashed with Zephyr's Peripheral application(peripheral_csc). In this case, we just getting 18 meters line of sight (indoor environment), Connection starts dropping as soon as we put the wooden door obstacles in the path.
 
In this case, We have a concern regarding the 'Max Range' till which our custom board's nrf52840 chip would be able to maintain the connection with the dev kit.
 
Please note: We have flashed Beacon application on our custom board having "nrf52840_pca10056" chip and it was visible more than 100 meters of range. But with connectable devices, our custom board is not able to communicate the BLE device which is available more than 18 meters range.
 
Q1: How could we increase the connection range with a more stable connection?
Zephyr Configurations:
In Zephyr's 'hci_uart' application, 
1) We have changed 'Tx power' parameter to 8 dbm (Highest).
2) Enabled 'Coded PHY' along with the '2Mbps PHY' to increase the BLE range.3) We are using the RC oscillator crystal with "CLOCK_CONTROL_NRF_K32SRC_20PPM" option.
 
Q2: Are there any more parameters that we can enable from zephyr, which could help in increasing the long-range BLE communication?
Q3: As of now, We are using Bluez stack's & Linux kernel's default parameters, Is there any BLE connection parameters which could help in increasing the long-range BLE communication?


Duarte Nogueira: LIBERTEM A ELEFANTE BAMBI

Marcio Montenegro
 

Olá,

Eu acabei de assinar o abaixo-assinado "Duarte Nogueira: LIBERTEM A ELEFANTE BAMBI" e queria saber se você pode ajudar assinando também.

A nossa meta é conseguir 200.000 assinaturas e precisamos de mais apoio. Você pode ler mais sobre este assunto e assinar o abaixo-assinado aqui:

http://chng.it/zVM9JvLdfC

Obrigada/Obrigado!
Marcio


Duarte Nogueira: LIBERTEM A ELEFANTE BAMBI

Marcio Montenegro
 

Olá,

Eu acabei de assinar o abaixo-assinado "Duarte Nogueira: LIBERTEM A ELEFANTE BAMBI" e queria saber se você pode ajudar assinando também.

A nossa meta é conseguir 200.000 assinaturas e precisamos de mais apoio. Você pode ler mais sobre este assunto e assinar o abaixo-assinado aqui:

http://chng.it/zVM9JvLdfC

Obrigada/Obrigado!
Marcio


Upcoming Event: Zephyr Project: Dev Meeting - Thu, 07/09/2020 3:00pm-4:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 9 July 2020, 3:00pm to 4:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Re: Dev-Review Meeting Agenda Jul 9

Peter A. Bigot
 

Two items for dev-review:
* https://github.com/zephyrproject-rtos/zephyr/pull/26025#issuecomment-656044858 against https://github.com/zephyrproject-rtos/zephyr/pull/26750#discussion_r452120857 and the question of whether optional API should be declared or not relative to use of `if (IS_ENABLED())`.  This may also be appropriate for API.
* https://github.com/zephyrproject-rtos/zephyr/pull/24794#pullrequestreview-444964843
 


Zephyr: Toolchain Working Group - Thu, 07/09/2020 #cal-notice

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Zephyr: Toolchain Working Group

When:
Thursday, 9 July 2020
2:00pm to 3:00pm
(GMT+00:00) UTC

Where:
Microsoft Teams Meeting

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Upcoming Event: Zephyr: Toolchain Working Group - Thu, 07/09/2020 2:00pm-3:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr: Toolchain Working Group

When: Thursday, 9 July 2020, 2:00pm to 3:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: Maureen Helm

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Dev-Review Meeting Agenda Jul 9

Kumar Gala
 

Here’s the agenda topics for this week:

* Any PR/issues w/dev-review tag

https://github.com/zephyrproject-rtos/zephyr/labels/dev-review

* Any topics anyone else has.

- k


Zephyr Toolchain Working Group Meeting – 09 July 2020

Rasmussen, Torsten
 

Agenda

  • Updates:
  • Short term goals, way forward
    • Dedicated toolchain test cases.
    • Label PR for automatic execution of CI Toolchain test cases

 

 

Feel free to send a mail, if you would like additional topics to be discussed.

 

Best regards

 

Torsten T. Rasmussen           

 

Live meeting minutes: https://docs.google.com/document/d/1IQKBK-GcJNZG0O9QArqYfvb6Huk5xHscN-XIGEZr-z8/edit#heading=h.x36xe8bnwr9r

________________________________________________________________________________

 

Join Microsoft Teams Meeting

+1 321-558-6518 United States, Orlando (Toll)

Conference ID: 682 738 030#

Local numbers | Reset PIN | Learn more about Teams | Meeting options

 

________________________________________________________________________________

 

 

 

Torsten Tejlmand Rasmussen

Senior R&D Engineer

P: +47 72 89 92 47

 

Nordic

 

Nordic Semiconductor

Otto Nielsens veg 12, 7052 Trondheim, Norway

www.nordicsemi.com

 

 

SM_symbol_FB  nordic_symbol_small_TW  nordic_symbol_small_YT_ny2  nordic_symbol_small_IN  

 

DevZone

           

 


Re: Post 2.3.0 PR merging

Simon Glass
 

Hi Anas,

Less scientifically I just did some reviews and perhaps half of them already had one approval. So presumably they were blocked. I guess you are saying it's only a third. OK. But that's a lot. Also with two reviewers, people can be somewhat less careful...

How do you deal with the case of people being happy with it but wanting review from someone else before approving? I saw a few where it seemed no one would take the plunge.

Regards,
SImon


On Tue, 7 Jul 2020 at 12:57, Nashif, Anas <anas.nashif@...> wrote:

Hi,

 

Here some data…

 

What I have just posted on slack…

 

 

So, go do some reviews please 😊

 

 

Thanks

Anas

 

From: <devel@...> on behalf of Carles Cufi <carles.cufi@...>
Date: Tuesday, 7 July 2020 at 06:42
To: Simon Glass <sjg@...>
Cc: "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Simon,

 

Not to my knowledge, no. But perhaps Ioannis or Anas know if it’s also documented elsewhere. 

 

Regarding the “stamp of approval” that was mentioned earlier in the thread, I think we could adopt a middle ground. If the person with merge rights is reasonably knowledgeable about the area of the change, and understands the implications, their +1 could count even if they are not a maintainer. I feel that in many cases this could unblock PRs without compromising the quality of the code being merged. 

 

Carles 



Am 06.07.2020 um 22:20 schrieb Simon Glass <sjg@...>:

Hi Carles,

 

OK I see. Since you called out the 2-approver change as a cause of the bottleneck, I'm assuming there is data available on this.

 

I was looking around for discussion about the decision. The closest I found was here. Is there something else?

 

Regards,

SImon

 

 

On Mon, 6 Jul 2020 at 12:23, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles


RFC: API Change: watchdog: wdt_feed error codes

Peter A. Bigot
 

Following https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html#stable we have a need to make a small change to the watchdog API that meets the criteria of "...forces users to modify their existing code in order to maintain the current behavior of their application".

Please see: https://github.com/zephyrproject-rtos/zephyr/issues/26708

Peter


New topic branch: topic-usb

Carles Cufi
 

Hi all,

The current subset of USB device classes implemented by Zephyr is now fairly complete, so we are ready to tackle the long needed cleaning up of the USB structures and classes that the USB maintainers have wanted to do for a while now.

I have therefore created a topic-usb branch to prototype and later implement the required changes in the USB API to finally clean up the cruft that has been building up over the years, and add support for the type of functionality that has been long requested but we never had the time for.

If you are interested in the changes to the USB structures and APIs that will be discussed in this branch, please take a look at the Pull Requests targeting it:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Atopic-usb

Regards,

Carles


Re: SDK 0.11.4 Release

Stephanos Ioannidis
 

To elaborate, there is a critical bug in the GCC 8.3.0 (included in the Zephyr
SDK 0.10.3) that causes it to emit incorrect instructions for the ARC targets.
(see https://github.com/zephyrproject-rtos/zephyr/issues/26659)

This issue seems to be fixed in the GCC 9.x, so we need to release a new SDK,
that is compatible with the 1.14 LTS release, with GCC 9.x (or alternatively,
update the 1.14 LTS so that it can be used with the latest release of Zephyr
SDK, but I am not sure how feasible that would be).

Stephanos

p.s. another reason to use the Zephyr version number as the base for the SDK
version numbers (cc @tejlmand)

-----Original Message-----
From: devel@... <devel@...> On Behalf Of Wu, Wentong via lists.zephyrproject.org
Sent: Wednesday, July 8, 2020 1:05 PM
To: Kumar Gala <kumar.gala@...>; zephyr-users@...; zephyr-devel <zephyr-devel@...>; announce@...
Subject: Re: [Zephyr-devel] SDK 0.11.4 Release

Any plan to have 1.14 LTS branch upgrading SDK as master does? IMHO, we should do that because we claim it's LTS branch.

Thanks

-----Original Message-----
From: devel@... <devel@...> On Behalf Of Kumar Gala
Sent: Friday, June 26, 2020 10:46 AM
To: zephyr-users@...; zephyr-devel <zephyr-devel@...>; announce@...
Subject: [Zephyr-devel] SDK 0.11.4 Release

Hi,

Some minor fixes related to newlib and a packaging related fix for the individual arch toolchain packages (missing the cmake files)

The SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.11.4

Please download and try things out and report any issues.

- General:
* Fixed issue with cmake files not being installed in arch specific
toolchan packages

- newlib:
* Fix setting of -DMISSING_SYSCALL_NAMES consistent on all builds
* Set march=pentium for 32-bit x86 build

- k


Re: SDK 0.11.4 Release

Wu, Wentong
 

Any plan to have 1.14 LTS branch upgrading SDK as master does? IMHO, we should do that because we claim it's LTS branch.

Thanks

-----Original Message-----
From: devel@... <devel@...> On Behalf Of Kumar Gala
Sent: Friday, June 26, 2020 10:46 AM
To: zephyr-users@...; zephyr-devel <zephyr-devel@...>; announce@...
Subject: [Zephyr-devel] SDK 0.11.4 Release

Hi,

Some minor fixes related to newlib and a packaging related fix for the individual arch toolchain packages (missing the cmake files)

The SDK can be found here:

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.11.4

Please download and try things out and report any issues.

- General:
* Fixed issue with cmake files not being installed in arch specific
toolchan packages

- newlib:
* Fix setting of -DMISSING_SYSCALL_NAMES consistent on all builds
* Set march=pentium for 32-bit x86 build

- k


Re: Post 2.3.0 PR merging

Nashif, Anas
 

Hi,

 

Here some data…

 

What I have just posted on slack…

 

 

So, go do some reviews please 😊

 

 

Thanks

Anas

 

From: <devel@...> on behalf of Carles Cufi <carles.cufi@...>
Date: Tuesday, 7 July 2020 at 06:42
To: Simon Glass <sjg@...>
Cc: "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Simon,

 

Not to my knowledge, no. But perhaps Ioannis or Anas know if it’s also documented elsewhere. 

 

Regarding the “stamp of approval” that was mentioned earlier in the thread, I think we could adopt a middle ground. If the person with merge rights is reasonably knowledgeable about the area of the change, and understands the implications, their +1 could count even if they are not a maintainer. I feel that in many cases this could unblock PRs without compromising the quality of the code being merged. 

 

Carles 



Am 06.07.2020 um 22:20 schrieb Simon Glass <sjg@...>:

Hi Carles,

 

OK I see. Since you called out the 2-approver change as a cause of the bottleneck, I'm assuming there is data available on this.

 

I was looking around for discussion about the decision. The closest I found was here. Is there something else?

 

Regards,

SImon

 

 

On Mon, 6 Jul 2020 at 12:23, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles


Upcoming Event: Zephyr Project: APIs - Tue, 07/07/2020 4:00pm-5:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 7 July 2020, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Steval drone flight control support

Brenton Chetty <brent7984@...>
 

Hi, I've noticed that the steval_fcu001v1 board is supported on Zephyr, however I could not find an example with the flight control software. Does anyone know if any work has been done with regards to this integration. If not, could you please point me in the right direction with regards to how to integrate flight control with zephyr.

With regards
Brenton


Re: Post 2.3.0 PR merging

Carles Cufi
 

Hi Simon,

Not to my knowledge, no. But perhaps Ioannis or Anas know if it’s also documented elsewhere. 

Regarding the “stamp of approval” that was mentioned earlier in the thread, I think we could adopt a middle ground. If the person with merge rights is reasonably knowledgeable about the area of the change, and understands the implications, their +1 could count even if they are not a maintainer. I feel that in many cases this could unblock PRs without compromising the quality of the code being merged. 

Carles 

Am 06.07.2020 um 22:20 schrieb Simon Glass <sjg@...>:


Hi Carles,

OK I see. Since you called out the 2-approver change as a cause of the bottleneck, I'm assuming there is data available on this.

I was looking around for discussion about the decision. The closest I found was here. Is there something else?

Regards,
SImon



On Mon, 6 Jul 2020 at 12:23, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Simon,

 

A decision like that would need to go through the TSC, and in order to be able to vote we’d need to have clear stats on how many PRs are actually blocked by this policy. I was thinking about this recently, and given that those in Zephyr with merge rights can in fact add their +1 and they typically rely on a maintainer’s review to decide whether to merge a PR or not, this might not have as big as an impact as I originally thought.

 

That said, I believe we need a new GitHub filter to help us. Right now, we have one that lists PRs that are approved, passing CI and ready to merge, but what we need is one that shows all PRs that are partially approved (i.e. a single +1) and passing CI. Then those of us with merge rights could go over those regularly (like we do for the former) and, provided there’s a +1 from a maintainer, we could take one additional look at the PR, approve it and merge it.

 

I’d very much like to hear the opinion of others with merge rights in this thread.

 

Regards,

 

Carles

 

From: Simon Glass <sjg@...>
Sent: 06 July 2020 19:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Post 2.3.0 PR merging

 

Hi Carles,

 

On Fri, 12 Jun 2020 at 03:19, Carles Cufi <carles.cufi@...> wrote:

Hi all,

We currently have 170+ Pull Requests that pass CI but require one or more approvals in order to be merged, in part due to the fact that we have increased the minimum number of approvals required from 1 to 2.

 

Perhaps given the situation this should be reversed?

 

Regards,

Simon 

 


Help reviewing those PRs is greatly appreciated:

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+base%3Amaster+review%3Arequired+status%3Asuccess+-label%3ADNM+draft%3Afalse

Thanks,

Carles


API meeting agenda: 2020-07-07

Peter A. Bigot
 

Carles has asked me to stand in for him again in coordinating this week's API telecon.

Topics include:

https://github.com/zephyrproject-rtos/zephyr/pull/26305 adding mode flags to fs_open

https://github.com/zephyrproject-rtos/zephyr/pull/26173 detecting Arduino-style reset requests on CDC-ACM

I'd also like to run through the 19 items remaining in triage, moving some to To-Do, In-Progress, or On-Hold/Abandoned.  I've already moved the SFDP one to In-Progress; there are others that I think no longer need to be on the to-discuss queue.

Teams link: https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit