Date   

Re: RFC: Initializing and placement of thread/fiber/task stacks

Andy Ross
 

Mitsis, Peter wrote:
Thread stacks (as defined by the __stack attribute) should be placed
into their own section. By default this section should be a part of
the .noinit section so that they do not impact run time
performance. However, if the Kconfig option INIT_STACKS is enabled,
then the stacks should be placed into their own unique section and
their stack space should be initialized at boot time to a known
value (0xaa).
+1 from me at least. Nothing in any relevant platform standards I'm
aware of say anything about unused stack contents at thread start or
entry to main(), and programmers and compilers have generating robust
code in these stacks for decades. It's routine to throw malloc()
output at pthreads for a stack, for example.

Andy


RFC: Initializing and placement of thread/fiber/task stacks

Mitsis, Peter <Peter.Mitsis@...>
 

Any objections/comments to the following?

Thread stacks (as defined by the __stack attribute) should be placed into their own section. By default this section should be a part of the .noinit section so that they do not impact run time performance. However, if the Kconfig option INIT_STACKS is enabled, then the stacks should be placed into their own unique section and their stack space should be initialized at boot time to a known value (0xaa).

Although this will result in a longer boot time (when INIT_STACKS) is enabled, it means that aside from the potential boot time penalty, there is never a stack initialization run time penalty when creating a thread. This may be particularly beneficial should a thread be restarted or thread-space be reused as the stack will not be re-initialized. Note that this changes the semantics of thread stack usage to mean thread stack usage for all threads that use that stack.

Peter Mitsis


Main thread (and stack) isn't the (only) main

Paul Sokolovsky
 

Hello,

This post is probably should be treated as user feedback in
justification of unified kernel *and* getting rid of .mdef files
https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/thread/P3JQWLBJPZ37NDAXRV54DRXMXSEM35CK/#P3JQWLBJPZ37NDAXRV54DRXMXSEM35CK

So, I started a port of a scripting language (MicroPython), initially
low-profile, starting with nanonkernel. Knowing that a scripting
language would require extended stack space, I bumped
CONFIG_MAIN_STACK_SIZE to 4K. Proceeding to add networking
capabilities, I switched to microkernel (as nanokernel demonstrated
some weird behavior). Now I understand that's where problem spot was -
CONFIG_MAIN_STACK_SIZE appear to apply (mostly) to nanokernel. But I
would need to be very proficient in Zephyr to know that beforehand.
Because description of that option is:

config MAIN_STACK_SIZE
int
prompt "Background task stack size (in bytes)"
default 1024
help
This option specifies the size of the stack used by the kernel's
background task, whose entry point is main().

So, no clear warning that it applies only to nanokernel's main() and
not microkernel main().

Going next, I enabled mbedTLS, and that's when I started to get
mysterious crashes - connecting to some sites, but not the others.
Clearly looked like stack related, so I bumped CONFIG_MAIN_STACK_SIZE
to 16K, and as that didn't help, network RX and TX threads. That
didn't help still, I tried to reach for GDB
(https://lists.zephyrproject.org/archives/list/devel(a)lists.zephyrproject.org/thread/TOEAZ6AM7JNIZMR4IUZG5SKQGHTBRDVC/),
that didn't help, so I resorted to printf(), and confirmed that a
stack was smashed when I got a crash. The only mystery was why it
keeps being smashed while I kept increasing it. And reaching to a .map
file, I saw that besides "main_task_stack", which was 16K as I set it,
there's some "__MAIN_stack" with a lowy 4K, and smashing occurs inside
it.

It took just a grep over entire tree to figure out that "MAIN" stack
comes from an .mdef file (which I of course just copy-pasted) and bump
it to have the issue resolved.


So, this is clearly a user error, but the whole matter is pretty
confusing, as I experienced first-hand. There're some things which could
be improved, like wording of nanokernel/MAIN_STACK_SIZE and perhaps var
naming (if it's *default task*, maybe its stack should be
default_task_stack).

But of course, even better would be to switch to unified kernel and get
rid of multiple ways to specify app params (I'm talking about .mdef).
So, my firm +1 on that. And grepping thru the tree, I see that
unified/ has its own Kconfig with MAIN_STACK_SIZE description
updated. Is it ready for testing by "end users"? Does it have .mdef
eliminated?


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Exception debugging with qemu_x86/gdb

Paul Sokolovsky
 

Hello Andrew,

On Mon, 19 Sep 2016 16:14:38 +0000
"Boie, Andrew P" <andrew.p.boie(a)intel.com> wrote:

On Sat, 2016-09-17 at 23:53 +0300, Paul Sokolovsky wrote:
I would naively think that QEMU's GDB stub would override any
relevant guest exception handling, but that apparently not happen.
I'm not sure how we could get QEMU's stubs in Zephyr's IDT to be
honest.
Thanks for the reply. To clarify, my thinking was that QEMU *might*
work in the following manner: if it's run in GDB stub mode, when it
during emulation detected a typical CPU exception (access violation,
invalid opcode), then instead of emulation calling a particular
exception vector as set in a guest, it could just halt guest, and make
its own GDB stub to communicate required state to GDB. As I mentioned,
I had no idea if it works like that or not, so wondered what other
people experienced.

So, I assume there's no special support in QEMU for that, and any
follow up should be brought on QEMU mailing list.

It may be the case that we could do some work on the Zephyr x86
exception handling stubs to be more GDB friendly. I don't know off the
top of my head what it would take to get 'backtrace' to work the way
you describe. We might just need to massage the stack a bit and issue
a debugger 'break' in the error handler.
Sound like good idea, I hope to try it next time I face similar
debugging needs.

Currently, for x86 exceptions with CONFIG_EXCEPTION_DEBUG turned on
we install a bunch of handler stubs, you can see the code in
arch/x86/core/fatal.c. That is what prints out the message. It then
calls _SysFatalErrorHandler which either aborts the thread or spins
forever.

Faulting segment:address = 0x00000008:0x001782da
This is where your code is generating an exception. I'd set a
breakpoint there.
Thanks, yes, I looked at those places. Fairly speaking, the issue
looked like a stack smashing from the beginning, and trying to debug it
with GDB by trying to catch it with break-points and stepping didn't
give any result. So, I had to resort to printf debugging, which rarely
fails someone (but takes enormous of time). It indeed turned out to be
stack smashing, but not somewhere I could expect (because I already
increased stack sizes of threads I knew about). I'll send detail in a
separate email.



Andrew

Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: [TCP/IPv4] Sending out Ethernet packets appear to have issues

Paul Sokolovsky
 

Hello,

Well, so this turned out to be the same issue reported among the first
by Rohit. I either forgot details or mixed it up - I thought that if it
involved uIP context set to NULL, it would end in crash, but it indeed
actually picks up random memory value from an address like 0x4 to use
for MSS, etc. The fix is literally one-line, please review:
https://gerrit.zephyrproject.org/r/#/c/4888/


Thanks,
Paul


On Tue, 20 Sep 2016 01:03:42 +0300
Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote:

Hello,

I'm continuing testing of Marcus Shawcroft's FRDM-K64F Ethernet
driver: https://gerrit.zephyrproject.org/r/#/c/4446 . Initial testing
using echo_server seems to be ok, but trying to initiate connection
from device has issues. Specifically, of "GET /foo HTTP/1.0\r\n\r\n"
request I use, only "GE" is being send out.

One thing I noticed is that eth_ksdk.c uses uip_len(buf) for packet
length, while net_driver_ethernet_send() which calls it, dumps
buf->len. Usage of uip_len(buf) comes from reference driver eth_dw.c
(I assume).

I dumped both lengths and here's how it looks:

net: net_driver_ethernet_send (0x200150d4): Sending 54 bytes
uip_len=44 Smashed net_buf with ARP request
net: net_driver_ethernet_send (0x200150d4): Really sending 54 bytes
eth: sending 42 bytes (buf->len=54)
net_context_tcp_init()=0
waiting to connect: -119
net: net_driver_ethernet_send (0x200178d4): Sending 54 bytes
uip_len=44 Didn't smash net_buf with ARP request
net: net_driver_ethernet_send (0x200178d4): Really sending 54 bytes
eth: sending 58 bytes (buf->len=54)
net: net_rx_fiber (0x200170d4): Received buf 0x20001bc0
s.write("GET /foo HTTP/1.0\r\n\r\n")
socket_write(2000d1d0, 2000d430, 21)
net: net_send (0x200150d4): context 0x2000c8b8 buf 0x20007304 status 0
net: net_tx_fiber (0x200174d4): Sending (buf 0x20007304, len 75) to
IP stack net: net_driver_ethernet_send (0x200174d4): Sending 75 bytes
uip_len=42 Didn't smash net_buf with ARP request
net: net_driver_ethernet_send (0x200174d4): Really sending 75 bytes
eth: sending 56 bytes (buf->len=75)

So, one can say that uip_len(buf) and buf->len isn't well
synchronized. With the last packet, which contains user data, if
buf->len was used, then all data probably would have been sent.
However before, there can be seen can when len->buf is 54, but
uip_len(58).

All that stuff works now pretty well with QEMU/SLIP. So, my plan is to
see what SLIP driver does and try to do the same. Of course, the issue
may be more complicated, like both Z and uIP trying to add Ethernet
header, in different combinations for different packet types.


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Porting to ARM Cortex-M7 / Atmel SAM E70 support

Kumar Gala
 

On Sep 21, 2016, at 10:18 AM, Piotr Mienkowski <Piotr.Mienkowski(a)schmid-telecom.ch> wrote:

I would like to add support for Atmel SAM E70 SoC (Cortex-M7) and keep this thread to discuss all related issues.

A few questions that I have at the moment:

1) I created a relevant Jira issue ZEP-759 https://jira.zephyrproject.org/browse/ZEP-759. However, after reading "Collaboration Guidelines" wiki section I am still not sure if I'm allowed to start submitting commits to Gerrit or I should rather wait until someone officially accepts the Jira issue and assigns it to me?
There isn’t any need for the Jira to be accepted to submit code

2) The Jira issue I created is quite broad (I assumed however that it is not broad enough to be turned into an epic). Shall I create an additional task for each thing that needs to be done, e.g.: add Atmel SAM E70 header files, add support for ARM Cortex-M7 processor, add SAM E70 GPIO driver, add SAM E70 UART driver, etc.? Gerrit commits would then be assigned a Jira task number and not the broad Jira issue number.

As discussed in "Porting to Cortex-M0+" thread to add support for Atmel SoCs we would preferably use original Atmel header files provided as part of their ASF (Atmel Software Framework) library. At the moment we are waiting for Atmel to hopefully provide us with header files containing a Zephyr compatible license. As it was suggested in "Porting to Cortex-M0+" thread, I will submit code which adds support for Atmel SAM E70 SoC (and depends on ASF) to Gerrit so it can be reviewed. The commits could be merged later once the license issue is sorted out. Before I can proceed there are still a few things which needs to be decided.
If you want to break up or add sub-tasks to the Jira that is fine, but I wouldn’t get too fine grain with it. I think something like:
* Add Cortex-M7 support
* Add SoC support
* Add Board support


3) What should be the location of Atmel header files provided as part of ASF library? Maureen Helm, the ARM maintainer, proposed ext/hal/asf. I would like to suggest ext/hal/atmel on the basis that vendor library names are often cryptic and companies tend to change these names every several years. Within ext/hal/atmel each subfolder would have the name of a SoC family, the same as in arch/arm/soc/atmel.
Are there different ASFs per SoC or does Atmel release a single one for all their SoCs?

4) To support Cortex-M7 processor I need to add a new memory_map file. The existing one include/arch/arm/cortex_m/memory_map-m3-m4.h is specific to M3, M4 processors. However, the only differences between M3, M4 and M7 are in _PPB_EXT_* defines and they are never used. So my proposal is to remove all _PPB_EXT_* defines apart from _PPB_EXT_BASE_ADDR, _PPB_EXT_END_ADDR and re-use the file for M7. Very much the same defines could also be used by M0 processors. The only difference in that case is that M0, M0+ do not have ITM (Instrumentation Trace Macrocell) section and FPB section is called BPU. We could put all these defines directly in memory_map.h file and handle the minor differences via preprocessor #if defined() statements. Suggestions are welcomed.
Let’s merge these files down and use some #ifdef’s in just memory_map.h. I’ve submitted a patch to start that process:

https://gerrit.zephyrproject.org/r/#/c/4887/

- k


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 5
[ZEP-948] Revisit the timeslicing algorithm
https://jira.zephyrproject.org/browse/ZEP-948

[ZEP-947] CPU exception 13 and Fatal ISR error when irq_offload() exit
https://jira.zephyrproject.org/browse/ZEP-947

[ZEP-953] CONFIG_HPET_TIMER_DEBUG build warning
https://jira.zephyrproject.org/browse/ZEP-953

[ZEP-951] CONFIG_GDB_INFO build not working on ARM
https://jira.zephyrproject.org/browse/ZEP-951

[ZEP-950] USB: Device is not listed by USB20CV test suite
https://jira.zephyrproject.org/browse/ZEP-950


UPDATED JIRA items within last 24 hours: 6
[ZEP-421] Application Development Primer Rewrite
https://jira.zephyrproject.org/browse/ZEP-421

[ZEP-924] Revise documentation for Interrupts
https://jira.zephyrproject.org/browse/ZEP-924

[ZEP-910] Adapt tickless idle for x86
https://jira.zephyrproject.org/browse/ZEP-910

[ZEP-923] Revise documentation for Timing
https://jira.zephyrproject.org/browse/ZEP-923

[ZEP-779] Using current MinGW gcc version 5.3.0 breaks Zephyr build on Windows
https://jira.zephyrproject.org/browse/ZEP-779

[ZEP-686] docs: Info in "Application Development Primer" and "Developing an Application and the Build System" is largely duplicated
https://jira.zephyrproject.org/browse/ZEP-686


CLOSED JIRA items within last 24 hours: 2
[ZEP-906] (Fixed) [unified] Add scheduler time slicing support
https://jira.zephyrproject.org/browse/ZEP-906

[ZEP-898] (Fixed) Remove 1MB limit in file system
https://jira.zephyrproject.org/browse/ZEP-898


RESOLVED JIRA items within last 24 hours: 4
[ZEP-907] (Fixed) Test memory pool support (with mailboxes)
https://jira.zephyrproject.org/browse/ZEP-907

[ZEP-908] (Fixed) Add task offload to fiber support
https://jira.zephyrproject.org/browse/ZEP-908

[ZEP-614] (Fixed) Port tinycrypt 2.0 test cases to Zephyr
https://jira.zephyrproject.org/browse/ZEP-614

[ZEP-746] (Fixed) API documentation doesn't link to conceptual documentation
https://jira.zephyrproject.org/browse/ZEP-746


Porting to ARM Cortex-M7 / Atmel SAM E70 support

Piotr Mienkowski <piotr.mienkowski@...>
 

I would like to add support for Atmel SAM E70 SoC (Cortex-M7) and keep this thread to discuss all related issues.

A few questions that I have at the moment:

1) I created a relevant Jira issue ZEP-759 https://jira.zephyrproject.org/browse/ZEP-759. However, after reading "Collaboration Guidelines" wiki section I am still not sure if I'm allowed to start submitting commits to Gerrit or I should rather wait until someone officially accepts the Jira issue and assigns it to me?

2) The Jira issue I created is quite broad (I assumed however that it is not broad enough to be turned into an epic). Shall I create an additional task for each thing that needs to be done, e.g.: add Atmel SAM E70 header files, add support for ARM Cortex-M7 processor, add SAM E70 GPIO driver, add SAM E70 UART driver, etc.? Gerrit commits would then be assigned a Jira task number and not the broad Jira issue number.

As discussed in "Porting to Cortex-M0+" thread to add support for Atmel SoCs we would preferably use original Atmel header files provided as part of their ASF (Atmel Software Framework) library. At the moment we are waiting for Atmel to hopefully provide us with header files containing a Zephyr compatible license. As it was suggested in "Porting to Cortex-M0+" thread, I will submit code which adds support for Atmel SAM E70 SoC (and depends on ASF) to Gerrit so it can be reviewed. The commits could be merged later once the license issue is sorted out. Before I can proceed there are still a few things which needs to be decided.

3) What should be the location of Atmel header files provided as part of ASF library? Maureen Helm, the ARM maintainer, proposed ext/hal/asf. I would like to suggest ext/hal/atmel on the basis that vendor library names are often cryptic and companies tend to change these names every several years. Within ext/hal/atmel each subfolder would have the name of a SoC family, the same as in arch/arm/soc/atmel.

4) To support Cortex-M7 processor I need to add a new memory_map file. The existing one include/arch/arm/cortex_m/memory_map-m3-m4.h is specific to M3, M4 processors. However, the only differences between M3, M4 and M7 are in _PPB_EXT_* defines and they are never used. So my proposal is to remove all _PPB_EXT_* defines apart from _PPB_EXT_BASE_ADDR, _PPB_EXT_END_ADDR and re-use the file for M7. Very much the same defines could also be used by M0 processors. The only difference in that case is that M0, M0+ do not have ITM (Instrumentation Trace Macrocell) section and FPB section is called BPU. We could put all these defines directly in memory_map.h file and handle the minor differences via preprocessor #if defined() statements. Suggestions are welcomed.

Thanks,
Piotr


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4868 : unified: Add tickless idle support for x86
- https://gerrit.zephyrproject.org/r/4866 : unified: Remove unused _nano_get_earliest_deadline()
- https://gerrit.zephyrproject.org/r/4881 : nano_work: Don't assert if work is pending on submit
- https://gerrit.zephyrproject.org/r/4879 : unified: change signature of k_sem_reset()
- https://gerrit.zephyrproject.org/r/4880 : nano_work: Add nano_work_pending
- https://gerrit.zephyrproject.org/r/4878 : test_mem_safe: fix breakage in unified kernel
- https://gerrit.zephyrproject.org/r/4877 : kernel: Fix for k_sem where counter is a unsigned int
- https://gerrit.zephyrproject.org/r/4867 : unified: Eliminate useless check in idle thread
- https://gerrit.zephyrproject.org/r/4872 : DO NOT MERGE: zpoll: asynchronous I/O framework
- https://gerrit.zephyrproject.org/r/4871 : zconfig.h: Add DEFINED() macro for expresion-legal ifdef-checking
- https://gerrit.zephyrproject.org/r/4873 : doc: add zoap.h to doxygen input
- https://gerrit.zephyrproject.org/r/4858 : drivers: pwm: re-design pwm API interfaces
- https://gerrit.zephyrproject.org/r/4859 : drivers: timer: cortex_m_systick remove dead code
- https://gerrit.zephyrproject.org/r/4869 : unified: Add legacy task_offload_to_fiber() routine
- https://gerrit.zephyrproject.org/r/4870 : unified: Make test_pend unified capable.
- https://gerrit.zephyrproject.org/r/4864 : unified: Remove obsolete wait_q.h macros
- https://gerrit.zephyrproject.org/r/4865 : unified: Remove #if 0 code block from wait_q.h
- https://gerrit.zephyrproject.org/r/4863 : unified: Remove references to obsolete task_timeout
- https://gerrit.zephyrproject.org/r/4862 : unified: Replace _nano_get_earliest_deadline()
- https://gerrit.zephyrproject.org/r/4855 : win-doc: Adds the dependency with the pthread library

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4800 : unified: fix some leftover K_<obj>_DEFINE macros
- https://gerrit.zephyrproject.org/r/4580 : net: yaip: Special handling for net_if for Quark SE devboard
- https://gerrit.zephyrproject.org/r/4463 : power_mgmt: Update Power Management device driver API
- https://gerrit.zephyrproject.org/r/4705 : power_mgmt: Mark old device pm API functions as deprecated
- https://gerrit.zephyrproject.org/r/4704 : power_mgmt: Update sample and drivers according to new pm device API
- https://gerrit.zephyrproject.org/r/4321 : Bluetooth: BR/EDR: Refactor distribution of security procedure status
- https://gerrit.zephyrproject.org/r/4488 : Bluetooth: SDP: Server: Support ServiceSearchRequest
- https://gerrit.zephyrproject.org/r/4487 : Bluetooth: SDP: Server: Support service record registration
- https://gerrit.zephyrproject.org/r/4486 : Bluetooth: SDP: Server: Initialize and accept incoming connections
- https://gerrit.zephyrproject.org/r/4555 : Bluetooth: HFP HF: SLC connection-Send/Parse BRSF
- https://gerrit.zephyrproject.org/r/4445 : ksdk: Build ksdk fsl_enet.c and fsl_phy.c
- https://gerrit.zephyrproject.org/r/4478 : fs: Adds file system API to get volume statistics
- https://gerrit.zephyrproject.org/r/4480 : fs: Add file system API to flush cache of an open file
- https://gerrit.zephyrproject.org/r/4485 : sample: fs: Add tests for fs_truncate and fs_statvfs
- https://gerrit.zephyrproject.org/r/4372 : fs: Adds file system API to grow or shrink a file
- https://gerrit.zephyrproject.org/r/4815 : tests/zoap: Add simple test for retransmission
- https://gerrit.zephyrproject.org/r/4814 : iot/zoap: Fix retrieving the token for every reply
- https://gerrit.zephyrproject.org/r/4813 : iot/zoap: Fix subtly wrong indentation
- https://gerrit.zephyrproject.org/r/4819 : tests/zoap: Add tests for the observe feature
- https://gerrit.zephyrproject.org/r/4816 : iot/zoap: Add support for observing resources
- https://gerrit.zephyrproject.org/r/4817 : iot/zoap: Add port information to network addresses
- https://gerrit.zephyrproject.org/r/4818 : iot/zoap: Add helpers for dealing with integer options
- https://gerrit.zephyrproject.org/r/4846 : doc: FIFO API uses first 32 bits of data items
- https://gerrit.zephyrproject.org/r/4358 : net: samples: Revamp QEMU-QEMU networking in echo_server & echo_client
- https://gerrit.zephyrproject.org/r/4624 : eth: Add ENC28J60 support into Paho's MQTT publisher example
- https://gerrit.zephyrproject.org/r/4823 : net: Make sure that local port selected by Zephyr gets used by uIP.
- https://gerrit.zephyrproject.org/r/4625 : eth: ENC28J60 sample application
- https://gerrit.zephyrproject.org/r/4623 : eth: Adjust ENC28J60 transmission/reception return codes.
- https://gerrit.zephyrproject.org/r/4844 : win-doc: Add recommendation for regex library configuration
- https://gerrit.zephyrproject.org/r/4852 : Bluetooth: Controller: Use net_buf for HCI RX

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4857 : drivers: timer: loapic remove unused workaround
- https://gerrit.zephyrproject.org/r/4876 : net: yaip: Remove nbr_data section as it is useless
- https://gerrit.zephyrproject.org/r/4860 : usb_dw: Clear device address on USB Reset
- https://gerrit.zephyrproject.org/r/4861 : test_mem_safe: bring x86 linker script up-to-date
- https://gerrit.zephyrproject.org/r/4856 : doc: fix title generation for config options pages
- https://gerrit.zephyrproject.org/r/4853 : Bluetooth: init: Add CONFIG_BLUETOOTH_A2DP to prj_20.conf
- https://gerrit.zephyrproject.org/r/4831 : net: yaip: Add more debugging prints to neighbor cache
- https://gerrit.zephyrproject.org/r/4833 : net: tests: Add tests for route management API
- https://gerrit.zephyrproject.org/r/4827 : net: yaip: Fix function prototype documentation in neighbor header
- https://gerrit.zephyrproject.org/r/4828 : net: yaip: Add function to return neighbor by the index
- https://gerrit.zephyrproject.org/r/4829 : net: yaip: Added a define for unused bytes length in ICMPv6 header
- https://gerrit.zephyrproject.org/r/4830 : net: yaip: Fix reachable timer accessing NULL pointer
- https://gerrit.zephyrproject.org/r/4849 : net: yaip: Add more debugging prints to neighbor cache
- https://gerrit.zephyrproject.org/r/4850 : net: yaip: Add ref counting debugging to neighbor cache
- https://gerrit.zephyrproject.org/r/4851 : net: yaip: Add IPv6 utility func to create IPv6 packet
- https://gerrit.zephyrproject.org/r/4832 : net: yaip: Generic route handling
- https://gerrit.zephyrproject.org/r/4797 : unified: Implement memory pools
- https://gerrit.zephyrproject.org/r/4799 : unified: Make memory pool test unified capable
- https://gerrit.zephyrproject.org/r/4798 : unified: Enable memory pools in mailbox tests
- https://gerrit.zephyrproject.org/r/4841 : x86: optimize GDT space
- https://gerrit.zephyrproject.org/r/4678 : irq: Add irq_is_enabled external interrupt API
- https://gerrit.zephyrproject.org/r/4679 : ARM: irq: Add _arch_irq_is_enabled external interrupt API
- https://gerrit.zephyrproject.org/r/4812 : x86: introduce new segmentation.h header
- https://gerrit.zephyrproject.org/r/4843 : doc: Add links from kernel API to overview docs
- https://gerrit.zephyrproject.org/r/4676 : ARM: irq: Do not clear pending IRQ when enabling them.
- https://gerrit.zephyrproject.org/r/4346 : net: yaip: Initial architecture documentation
- https://gerrit.zephyrproject.org/r/4347 : net: yaip: User connectivity API documentation
- https://gerrit.zephyrproject.org/r/4779 : unified: Add support for semaphore groups
- https://gerrit.zephyrproject.org/r/4776 : unified: Conditionally define __printf_like() macro
- https://gerrit.zephyrproject.org/r/4781 : unified: Enable semaphore group use in test_mail
- https://gerrit.zephyrproject.org/r/4780 : unified: Fix semaphore group tests
- https://gerrit.zephyrproject.org/r/4777 : unified: Include _timeout structure in tcs_base
- https://gerrit.zephyrproject.org/r/4784 : unified: Preemption check to include sched lock
- https://gerrit.zephyrproject.org/r/4785 : unified: Add timeslice support
- https://gerrit.zephyrproject.org/r/4810 : unified: Add _is_next_thread_current()


Re: zoap architecture question...

Nashif, Anas
 

Hi,
Vinicius can say more, but there was an early POC on top of the new stack a few weeks back, the plan is to move to new IP stack for 1.6 and ASAP. https://jira.zephyrproject.org/browse/ZEP-818 covers this.

As for LWM2M, there is no activity on this front yet, but intention and plan are there. See https://jira.zephyrproject.org/browse/ZEP-216.

Anas

-----Original Message-----
From: Marcus Shawcroft [mailto:marcus.shawcroft(a)gmail.com]
Sent: Wednesday, September 21, 2016 3:33 AM
To: Gomes, Vinicius <vinicius.gomes(a)intel.com>
Cc: devel(a)lists.zephyrproject.org
Subject: [devel] Re: zoap architecture question...

Hi Vinicius

On 20 September 2016 at 15:03, Vinicius Costa Gomes <vinicius.gomes(a)intel.com> wrote:

Just a little background: when I wrote sol-coap, for the Soletta
project, I took the opposite way, I tried to handle everything inside
sol-coap. In the end, some users were coding around some of the
"features".

zoap, for now, will stay out of users way, at the cost of some
repeated code. Later, hhen we have a couple of concrete use cases,
zoap will become more opinionated.

- corrupt packet, header incomplete (no message id)
-> ignore it
- corrupt packet, but header complete (included message id)
-> ignore unrecognized versions
-> respond with con on reset messages.

Lowering this logic into the coap layer encapsulates it in one place,
which should be simpler to verify, and, at least superficially should
simplify the implementation of coap consumers.... are there other
issues involved here that make is desirable to push such logic
upwards?
There are a couple of points that should be taken into consideration:

- zoap is largely independent of the network stack (by design) and it
doesn't have any buffers of its own;
- zoap doesn't have all the information to handle that correctly, for
example, an application may choose to ignore all invalid packets from
a multicast address, to avoid increasing the noise;
Thanks, I appreciate you taking the time to explain some of the relevant back ground issues.

But as always, if you have ideas (or patches :-) ) so we can reach the
middle ground faster, I am all ears.
Understood ;-)

... just two more questions...
- What are your thoughts / plan for zoap on yaip?
- Are you aware of anyone working on lwm2m over zoap ?

Cheers
/Marcus




Cheers
/Marcus
Cheers,
--
Vinicius


Data to send linux host from Zephyr app

Giribabu Gogineni <giribabu02061983@...>
 

Hi Dev team,

Currently i am working one POC.

Requirement is to send the raw data from zephyr app using qemu which
convert UDP and other linux host side application listening on same UDP
port to receive the data.

Steps followed :
1. Using /samples/drivers/uart/ application, compiling for QEMU.
2. To send the data from serial to UDP, mentioned the below configuration
in make file and running the app.
QEMU_EXTRA_FLAGS += -serial udp::4555

3. Other linux host side we are listening on netcat [ #nc -u -l -p 4555 ]

But the issue i am facing the data is not received from linux host side.

Could please suggest, if any step i am missing in this process.
Is there any other way, i can achieve the requirement.

Thanks in advance.

Regards,
Giribabu


Re: zoap architecture question...

Marcus Shawcroft <marcus.shawcroft@...>
 

Hi Vinicius

On 20 September 2016 at 15:03, Vinicius Costa Gomes
<vinicius.gomes(a)intel.com> wrote:

Just a little background: when I wrote sol-coap, for the Soletta
project, I took the opposite way, I tried to handle everything inside
sol-coap. In the end, some users were coding around some of the
"features".

zoap, for now, will stay out of users way, at the cost of some repeated
code. Later, hhen we have a couple of concrete use cases, zoap will
become more opinionated.

- corrupt packet, header incomplete (no message id)
-> ignore it
- corrupt packet, but header complete (included message id)
-> ignore unrecognized versions
-> respond with con on reset messages.

Lowering this logic into the coap layer encapsulates it in one place,
which should be simpler to verify, and, at least superficially should
simplify the implementation of coap consumers.... are there other
issues involved here that make is desirable to push such logic
upwards?
There are a couple of points that should be taken into consideration:

- zoap is largely independent of the network stack (by design) and it
doesn't have any buffers of its own;
- zoap doesn't have all the information to handle that correctly, for
example, an application may choose to ignore all invalid packets from
a multicast address, to avoid increasing the noise;
Thanks, I appreciate you taking the time to explain some of the
relevant back ground issues.

But as always, if you have ideas (or patches :-) ) so we can reach the
middle ground faster, I am all ears.
Understood ;-)

... just two more questions...
- What are your thoughts / plan for zoap on yaip?
- Are you aware of anyone working on lwm2m over zoap ?

Cheers
/Marcus




Cheers
/Marcus
Cheers,
--
Vinicius


Re: zepyr application to write on to UDP socket

Jukka Rissanen
 

Hi Giribabu,

do you mean IP header when you say "extra headers"?

If yes, then transferring raw UDP data without IP header is not
possible with current SLIP driver. You need to write your own driver
that would just transfer the data without any extra headers.


Cheers,
Jukka

On Tue, 2016-09-20 at 16:02 +0530, Giribabu Gogineni wrote:
Hi Jukka,

Thanks for the feedback. 
When we use echo client running on QEMU using SLIP and we have server
application running on linux host, we receive the extra headers along
with data.

Our requirement is pass the UDP data from zephyr app using QEMU and
receive the same exact UDP packet on linux host side.
Please let us know, if we have any solution for this.

Thanks in advance ...

Regards,
Giribabu 

On Thu, Sep 1, 2016 at 7:21 PM, Jukka Rissanen <jukka.rissanen(a)linux.
intel.com> wrote:
Hi Giribabu,

On Thu, 2016-09-01 at 17:15 +0530, Giribabu Gogineni wrote:
Hi Dev group,

In my application i want write UDP socket and send to linux host
using QEMU.

Is it possible to write an application to write payload on to UDP
socket?
That UDP socket is possible to send using QEMU to linux host?

Could you please help me, if sample application are available,
please
provide the path.
You can look how the echo-client and echo-server sample app do
things.

Those apps can be found at
        samples/net/echo_client
        samples/net/echo_server

For instructions how to setup the SLIP from Qemu see the
samples/net/README file. Various tools for SLIP can be found in
net-
tools project.

git clone https://gerrit.zephyrproject.org/r/p/net-tools.git

and check the README.legacy file in that directory.


Cheers,
Jukka


Re: Porting to Cortex-M0+

Piotr Mienkowski <piotr.mienkowski@...>
 

Why don’t you submit the code for review to at least let us move that bit along while we
figure out the issues with Atmel.
That's OK, I can do it.

Piotr


Re: [RFC]PWM API Update

Liu, Baohong
 

Hi all,

Thank you for your feedback and suggestions on this RFC.

I summarized what were discussed and would like to conclude this RFC.

There will be two APIs in include/pwm.h:

static inline int pwm_pin_set(struct device *dev, uint32_t pwm,
uint32_t period_cycles, uint32_t pulse_cycles);

static inline int pwm_pin_set_usec(struct device *dev, uint32_t pwm,
uint32_t period_usec, uint32_t pulse_usec);

Note: implementation of pwm_pin_set_usec API shall convert the
input (in usec) to cycles and then call pwm_pin_set.

I felt that get_cycles_per_sec() is not needed since there are already
constant definition for this. (e.g. CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC
in boards/arduino_101_sss/arduino_101_sss_defconfig).

The new API would replace the existing APIs so with that, all the existing APIs
(including API like pwm_all_set_xxx and the pwm_pin_configure which is not
Being used) will be marked as deprecated for 2 releases before they are
removed, based on the Zephyr policy.

Again, if any additional comments, please voice.

Thanks
Baohong

-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Friday, September 16, 2016 3:18 PM
To: Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com>;
devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: [RFC]PWM API Update



-----Original Message-----
From: Tomasz Bursztyka [mailto:tomasz.bursztyka(a)linux.intel.com]
Sent: Thursday, September 15, 2016 11:41 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: [RFC]PWM API Update

Hi Baohong,
-----Original Message-----
From: Ross, Andrew J
Sent: Thursday, September 15, 2016 8:04 AM
To: Liu, Baohong <baohong.liu(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] [RFC]PWM API Update

Liu, Baohong wrote:
As for the unit for period and pulse width, I understand that both
time
(micro-second) and clock cycles are popularly used. To cater for
this, the above-mentioned API will be expanded into two.

pwm_set_pin_usec(uint8_t pin, uint32_t period_usec, uint32_t
pulse_usec) pwm_set_pin_cycles(uint8_t pin, uint32_t
period_cycles, uint32_t pulse_cycles)
When PWM is used correctly, this shouldn't make any difference at
all because the period will be much, much longer than the
underlying clock (which is the whole point).

Why bother with having two ways to do this when they're going to be
exactly equivalent in all but the weirdest apps? Just set them in
arbitrary units of "cycles". And if an application really, truly
needs to know the underlying cycle time of the hardware (which is
going to be device-dependent), give them an API like
"pwm_get_cycle_time()" which returns a cycle time in picoseconds or
something.
I personally prefer two APIs. Somebody also suggested two APIs in ZEP-
745.
Looks two APIs is the way to go so far.
In the end, both do the same, but:

there is actually an implementation issue with pwm_set_pin_usec() as
the driver will have to do calculation according to the underlying hw cycle
time.
So this piles up more work in driver side. Though, from user
perspective, it might be simpler to use yes.
(no hand-computation needed from the user).

Actually, with Andy's proposal of providing a pwm_get_cycle_time()
along with pwm_set_pin_cycles(), I believe (tell me if I am wrong) you
could implement
pwm_set_pin_usec() as a generic pwm function instead of a driver API
function.
Sounds like the best option to me: you keep the driver API concise,
and you still end up providing both functions in the end.
I understand what you mean. I compared both methods. In my opinion,
there is no significant difference.

By the way, it looks odd to me to add pwm_get_cycle_time() into PWM
driver.
It should be a common utility function instead of a PWM API?

For now, let's go with what Andy and you proposed, unless I hear any strong
objection from others. That's:

pwm_set_pin(struct device *dev, uint8_t pin, uint32_t period_cycles,
uint32_t pulse_cycles); /* PWM API */
get_cycles_per_usec(void); /* we can find better name:) */

As you mentioned, the usec one will be a generic PWM function instead of a
API.


Tomasz


Re: RFC: async I/O facility: "zpoll" API

Andy Ross
 

As promised, the prototype is up for review here:

https://gerrit.zephyrproject.org/r/4871 zconfig.h: Add DEFINED() macro for expresion-legal ifdef-checking
https://gerrit.zephyrproject.org/r/4872 DO NOT MERGE: zpoll: asynchronous I/O framework

Note that it's a few patches behind. The semaphore group patch merged
while this was sitting on my box and they collide a bit. I'll get
that sorted out. Most of Ben's comments are still unaddressed, in
particular naming.

Other notes, just to preempt criticism:

+ There still aren't any real drivers ported to the new scheme, so
usage is a little academic right now. Priority 1 for me is getting
uart_qmsi working with this so I can push a test that makes sense.
Most drivers should port cleanly I think; the existing
driver_sync_call_t turns out to be a mostly perfect fit to be
reimplemented in terms of zpoll.

+ There is no true queueing for complete requests, so the actual
implementation of zpoll() itself is based on iterating over the set
of events. That was done originally to save having to bake a list
pointer into the event structure, but now that callbacks are in this
is unavoidable anyway. I'll get that fixed.

+ The pend/unpend mechanism was copied directly out of the semaphore
implementation so I didn't have to figure out exactly how it
works. :) So there's a wait_q in the call record which is needless,
as there can only ever be one thread pended.

Andy


Re: RFC: async I/O facility: "zpoll" API

Andy Ross
 

Benjamin Walsh wrote:
- This should be a native kernel feature. It should probably be called
k_poll rather than zpoll.
Will do. I'm calling it zpoll only because the semantics aren't
exactly equivalent to unix poll and I didn't want to address the
confusion. But that naming is probably better.

Shouldn't we have a pointer to a workqueue, so that the work could
be scheduled on another workqueue than the system one if desired ?
That seems reasonable. Though currently I'm envisioning the work
queue as purely a convenience feature above the lower level API. It's
there to issue the callbacks and that's it. Someone who wants finer
control over what happens when should be making the poll call directly
IMHO.

Shouldn't this be a union since one zpoll event instance should be
for one object ?

[...]

Where is zpoll_call defined ? Isn't that simply a k_tid_t ?
One zpoll_event struct goes with one request, and a bundle of them
with (zero or) one waiting thread blocked under zpoll(). That's what
the zpoll_call struct is, it's a private record stored on the stack of
the pended zpoll call. Basically it's the arguments to the function
and a list link, so the other threads can enumerate the pended threads
and events to figure out which ones are complete and who to wake up.


void _zpoll_sem_signal(struct k_sem *sem);
Do we need this ? Shouldn't this be the job of k_sem_give() to handle
waking up a thread from its polling ?
It is. This is the utility code that does that. It's hooked out of
k_sem_give(), checks one bit (which I stole from the count/limit) to
see if there's a blocked zpoll thread, then hands control to this
thing to wake it up. It's not strictly part of the API and got left
here because it's in the same header block I pasted in. :)

Andy


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 5
[ZEP-945] Add framework for provisioning-sytle device configuration
https://jira.zephyrproject.org/browse/ZEP-945

[ZEP-938] Samples/hello_world/nanokernel: Build fail, when enable CONFIG_RANDOM_GENERATOR=y
https://jira.zephyrproject.org/browse/ZEP-938

[ZEP-940] Fail to get ATT response
https://jira.zephyrproject.org/browse/ZEP-940

[ZEP-939] Different address used for advertising in non-connectable mode from oob data
https://jira.zephyrproject.org/browse/ZEP-939

[ZEP-946] Galileo Gen1 board support dropped?
https://jira.zephyrproject.org/browse/ZEP-946


UPDATED JIRA items within last 24 hours: 17
[ZEP-817] Neighbor Discovery Optimization for IPv6 over 6LowPAN
https://jira.zephyrproject.org/browse/ZEP-817

[ZEP-809] IPv6 over 802.15.4
https://jira.zephyrproject.org/browse/ZEP-809

[ZEP-804] IPv6 Addressing Architecture
https://jira.zephyrproject.org/browse/ZEP-804

[ZEP-805] Internet Control Message Protocol (ICMP) v6
https://jira.zephyrproject.org/browse/ZEP-805

[ZEP-807] Neighbor Discovery for IPv6
https://jira.zephyrproject.org/browse/ZEP-807

[ZEP-798] IPv6
https://jira.zephyrproject.org/browse/ZEP-798

[ZEP-823] New IP Stack - Documentation
https://jira.zephyrproject.org/browse/ZEP-823

[ZEP-852] SPI API Update
https://jira.zephyrproject.org/browse/ZEP-852

[ZEP-745] Revisit design of PWM Driver API
https://jira.zephyrproject.org/browse/ZEP-745

[ZEP-854] CoAP with DTLS sample
https://jira.zephyrproject.org/browse/ZEP-854

[ZEP-833] IP-to-IP tunneling support
https://jira.zephyrproject.org/browse/ZEP-833

[ZEP-233] Support USB mass storage device class
https://jira.zephyrproject.org/browse/ZEP-233

[ZEP-796] DHCPv4
https://jira.zephyrproject.org/browse/ZEP-796

[ZEP-767] Add FS API to flush cache of an open file
https://jira.zephyrproject.org/browse/ZEP-767

[ZEP-692] Newlib libraries in x86 SDK need non-hardware floating point version
https://jira.zephyrproject.org/browse/ZEP-692

[ZEP-539] Jenkins marks patches -1 verified for style issues
https://jira.zephyrproject.org/browse/ZEP-539

[ZEP-746] API documentation doesn't link to conceptual documentation
https://jira.zephyrproject.org/browse/ZEP-746


CLOSED JIRA items within last 24 hours: 2
[ZEP-757] (Fixed) tests/kernel/test_context/ fail in Arduino 101 and Quark SE C1000
https://jira.zephyrproject.org/browse/ZEP-757

[ZEP-895] (Fixed) Initial release to tx semaphore for the ENC28J60 driver.
https://jira.zephyrproject.org/browse/ZEP-895


RESOLVED JIRA items within last 24 hours: 2
[ZEP-808] (Fixed) IPv6 Stateless Autoconfiguration (SLAAC)
https://jira.zephyrproject.org/browse/ZEP-808

[ZEP-758] (Fixed) Rename Quark SE Devboard to its official name: Quark SE C1000
https://jira.zephyrproject.org/browse/ZEP-758


Re: RFC: async I/O facility: "zpoll" API

Benjamin Walsh <benjamin.walsh@...>
 

On Mon, Sep 19, 2016 at 01:22:14PM -0700, Andy Ross wrote:
So I've been looking at the requirement for an async I/O framework in
ZEP-540, and this is the API I have so far. An implementation is
prototyped as far as working with a minimal test of a faked device,
I'll get that cleaned up and in gerrit for a review within a day. But
here's the API I'm looking at. Please tear it apart as appropriate;
it's an API we'll be stuck with for a while. Stuff to note:

It works a little like Unix select()/poll(), in that the caller gets
handles to a bunch of "zpoll_event" structures which are 1:1 with
async requests made (e.g. they're a return value from a putative
uart_write_async() call), and can wait on the full set of them, waking
up with any one of them has a completion event to signal.

Driver's are responsible for managing one of these events per
simultaneous outstanding request they want to handle (in mose cases
that number of requests will be one), and calling a straightforward
signal() function when the request is complete (or in an error state).

Because mixing blocking styles is madness (c.f. the historical
disaster of pthreads and file descriptors not being waitable in the
same call and the need for hacks like signalfd), it also accepts basic
semaphores as a waitable object. We might consider some of the other
IPC primitives for the same treatment.

The original request was for a callback mechanism, which I resisted.
But given this mechanism and the existance of the system work queue
(which, to be fair, is a heavyweight feature), that's not hard to
implement. So this supports both styles, but the callback one is
optional for apps with their own main loops that don't want to have a
extra 1kb thread stack sitting around just for event processing.

Semantically, this overlaps in a kind of ugly way with
sem_group_take(), which I see a patch in the queue for. Essentially
zpoll() is a proper superset of that facility. We should probably try
to unify/deprecate such that we can do things in only one way.

Please review. An implementation prototype will arrive promptly.
OK, this is _very_ interesting. We were thinking of actuatlly
implementing a 'wait on multiple objects' in the kernel rather than just
this 'semaphore group' we currently have (for backwards compatibility
for now anyway).

I'm really eager to see the prototype.

A couple of nitpicks:

- I don't think the documentation should focus on drivers. The is usable
by applications as well.

- This should be a native kernel feature. It should probably be called
k_poll rather than zpoll.

More comments below.


Andy


========================================================================

typedef void (*zpoll_callback_t)(int result, void *user_data);

enum zpoll_req_type { ZPOLL_REQ_POLL, ZPOLL_REQ_SEM, ZPOLL_REQ_CALLBACK };

struct zpoll_event {
enum zpoll_req_type type : 8;
int signaled : 1; /* Driver/source operation complete */
int active : 1; /* result not yet retrieved/delivered */
int result;
union {
struct {
zpoll_callback_t callback;
void *user_data;
Shouldn't we have a pointer to a workqueue, so that the work could be
scheduled on another workqueue than the system one if desired ?

} cb;
struct {
Shouldn't this be a union since one zpoll event instance should be for
one object ?

struct zpoll_call *poller;
Where is zpoll_call defined ? Isn't that simply a k_tid_t ?

struct k_sem *semaphore;
} polled;
};
};

/**
* @brief Re/initialize zpoll event
*
* For use by drivers who are initiating a new request. Will return
* an error (-EAGAIN) if the event is still in use, which should
* generally be either propagated back to the user code making the
* request or used to initiate some kind of queuing/allocation of a
* new event. Drivers should *not* pend or busy-wait at request time
* to "wait" for this to become available. These are asynchronous
* requests!
*
* @param evt A potentially-in-use zpoll_event structure
*/
int zpoll_event_init(struct zpoll_event *evt);

#ifdef ZPOLL_CALLBACKS
/**
* @brief Re/initialize zpoll event for a user-specified callback
*
* As for zpoll_event_init(), but assigns the callback fields where provided.
*
* @param evt A potentitally-in-use zpoll_event structure
* @param cb A user-provided callback function
* @param user_data A user-provided opaque pointer to be passed as the
* user_data argument to the callback
*/
int zpoll_event_init_cb(struct zpoll_event *evt, zpoll_callback_t cb, void *user_data);
#endif

/**
* @brief Static initializer for a semaphore zpoll_event
*
* Constructs a zpoll_event stucture suitable for passing to zpoll().
*
* @param sem A pointer to a valid k_sem_t.
*/
#define ZPOLL_EVENT_SEMAPHORE(sem) \
{ \
.request_type = ZPOLL_REQ_SEM, \
.signaled = 0, \
.semaphore = (sem), \
}

/**
* @brief Executes the user-provided handler for a complete event
*
* Called by driver code when the request abstracted by this zpoll
* event is complete, either by waking up a pending zpoll() call or
* scheduling a work thread to issue the user-provided callback.
*
* @param evt A zpoll_event structure whose action is complete
* @param result The integer result code of the asynchronous call
*/
void zpoll_signal(struct zpoll_event *evt, int result);

void _zpoll_sem_signal(struct k_sem *sem);
Do we need this ? Shouldn't this be the job of k_sem_give() to handle
waking up a thread from its polling ? I suppose that you do not have to
give a semaphore knowing that it is waiting on by a thread using zpoll,
right ?

Or is this a hook to be called from k_sem_give(). It might be, since it
is named like an internal kernel function.

Hard to tell without documentation.

Regards,
Ben


/**
* @brief Wait for the completion of any of a number of events
*
* Will pend until any of the zpoll_event structures receives a
* zpoll_signal() call from another context (or, for semaphores, a
* "give" event), or until a the specified timeout occurs.
*
* For convenience, will return one known-complete event pointer. But
* note that completion notifications are "level triggered" (they stay
* complete and will synchronously wake up future zpoll calls until
* their results are retrieved), and that there may be more whose
* state can be tested with zpoll_get_result(). In general most
* applications will simply loop on zpoll() getting one event at a
* time.
*
* @param events An array of zpoll_event structures
* @param nevents The size of the events array
* @param timeout_ticks How long to wait before returning, or
* TICKS_UNLIMITED to wait forever.
*
* @return One complete event, or NULL if the timeout expired.
*/
struct zpoll_event* zpoll(struct zpoll_event **events, int nevents,
int timeout_ticks);

/**
* @brief Retrieve the result code of a complete zpoll_event and mark
* it available
*
* Returns the integer result code of the operation encapsulated by
* the zpoll_event. For driver-managed events, this also marks the
* zpoll_event available for future asynchronous I/O calls and so
* *must* be called to free the resource for future I/O.
*
* Will return -EAGAIN if the event is not yet complete.
*
* @return The result code of the asynchronous operation
*/
int zpoll_get_result(struct zpoll_event *e);


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/4852 : Bluetooth: Controller: Use net_buf for HCI RX
- https://gerrit.zephyrproject.org/r/4853 : Bluetooth: init: Add CONFIG_BLUETOOTH_A2DP to prj_20.conf
- https://gerrit.zephyrproject.org/r/4850 : net: yaip: Add ref counting debugging to neighbor cache
- https://gerrit.zephyrproject.org/r/4849 : net: yaip: Add more debugging prints to neighbor cache
- https://gerrit.zephyrproject.org/r/4837 : rfc: net: yaip: Add nbuf APIs to read/write across multiple fragments
- https://gerrit.zephyrproject.org/r/4851 : net: yaip: Add IPv6 utility func to create IPv6 packet
- https://gerrit.zephyrproject.org/r/4841 : x86: optimize GDT space
- https://gerrit.zephyrproject.org/r/4846 : doc: FIFO API uses first 32 bits of data items
- https://gerrit.zephyrproject.org/r/4842 : x86: make IDT setup optional
- https://gerrit.zephyrproject.org/r/4843 : doc: Add links from kernel API to overview docs

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4463 : power_mgmt: Update Power Management device driver API
- https://gerrit.zephyrproject.org/r/4705 : power_mgmt: Mark old device pm API functions as deprecated
- https://gerrit.zephyrproject.org/r/4704 : power_mgmt: Update sample and drivers according to new pm device API
- https://gerrit.zephyrproject.org/r/4321 : Bluetooth: BR/EDR: Refactor distribution of security procedure status
- https://gerrit.zephyrproject.org/r/4821 : drivers: gpio: reuse gpio Kconfigs for sensor subsystem
- https://gerrit.zephyrproject.org/r/4347 : net: yaip: User connectivity API documentation
- https://gerrit.zephyrproject.org/r/4346 : net: yaip: Initial architecture documentation
- https://gerrit.zephyrproject.org/r/4828 : net: yaip: Add function to return neighbor by the index
- https://gerrit.zephyrproject.org/r/4830 : net: yaip: Fix reachable timer accessing NULL pointer
- https://gerrit.zephyrproject.org/r/4832 : net: yaip: Generic route handling
- https://gerrit.zephyrproject.org/r/4829 : net: yaip: Added a define for unused bytes length in ICMPv6 header
- https://gerrit.zephyrproject.org/r/4833 : net: tests: Add tests for route management API
- https://gerrit.zephyrproject.org/r/4808 : Bluetooth: L2CAP: Limit user I/O actions timeout in GAP context
- https://gerrit.zephyrproject.org/r/4796 : Bluetooth: L2CAP: Handle security procedure non successful path
- https://gerrit.zephyrproject.org/r/4795 : Bluetooth: L2CAP: Refactor handling connection response
- https://gerrit.zephyrproject.org/r/4445 : ksdk: Build ksdk fsl_enet.c and fsl_phy.c
- https://gerrit.zephyrproject.org/r/4356 : tests: convert tests/net/buf to the new framework
- https://gerrit.zephyrproject.org/r/4357 : tests: Add a sample for testing natively
- https://gerrit.zephyrproject.org/r/4353 : ztest: Add native building support
- https://gerrit.zephyrproject.org/r/4118 : tests: Add a generic testing framework
- https://gerrit.zephyrproject.org/r/4812 : x86: introduce new segmentation.h header
- https://gerrit.zephyrproject.org/r/4623 : eth: Adjust ENC28J60 transmission/reception return codes.
- https://gerrit.zephyrproject.org/r/4813 : iot/zoap: Fix subtly wrong indentation
- https://gerrit.zephyrproject.org/r/4676 : irq: Add irq_enable_keep external interrupt API
- https://gerrit.zephyrproject.org/r/4446 : rfc: ksdk: Add KSDK ENET driver.
- https://gerrit.zephyrproject.org/r/3527 : console: shell: Shell enhancement - Support multiple modules
- https://gerrit.zephyrproject.org/r/4354 : ztest: Add documentation
- https://gerrit.zephyrproject.org/r/4555 : Bluetooth: HFP HF: SLC connection-Send/Parse BRSF
- https://gerrit.zephyrproject.org/r/27 : ci: test: checkpatch: warning space
- https://gerrit.zephyrproject.org/r/22 : ci: test: checkpatch: error braces
- https://gerrit.zephyrproject.org/r/4836 : lib/http: Add test-case for HTTP header fields
- https://gerrit.zephyrproject.org/r/3922 : lib: Add HTTP support for Zephyr
- https://gerrit.zephyrproject.org/r/4780 : unified: Fix semaphore group tests
- https://gerrit.zephyrproject.org/r/4781 : unified: Enable semaphore group use in test_mail
- https://gerrit.zephyrproject.org/r/4779 : unified: Add support for semaphore groups
- https://gerrit.zephyrproject.org/r/4810 : unified: Add _is_next_thread_current()
- https://gerrit.zephyrproject.org/r/4785 : unified: Add timeslice support

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/4847 : ieee802154_cc2520: Fix byte order swap for long address
- https://gerrit.zephyrproject.org/r/4848 : net: yaip: ieee802154: Endianess order is reversed on MAC
- https://gerrit.zephyrproject.org/r/4840 : Bluetooth: AVDTP: Add missing BLUETOOTH_DEBUG_AVDTP
- https://gerrit.zephyrproject.org/r/4839 : Bluetooth: init: Add CONFIG_BLUETOOTH_AVDTP to prj_20.conf
- https://gerrit.zephyrproject.org/r/4824 : tinycrypt: Add test case for the ECC DSA algorithm
- https://gerrit.zephyrproject.org/r/4825 : tinycrypt: Add test case for the ECC DH algorithm
- https://gerrit.zephyrproject.org/r/4794 : Bluetooth: A2DP: Initialization of A2DP
- https://gerrit.zephyrproject.org/r/4806 : net: yaip: Add IEEE 802.15.4 Beacon frame validation support
- https://gerrit.zephyrproject.org/r/4807 : net: yaip: tests: Add a simple IEEE 802.15.4 Beacon frame test

6501 - 6520 of 8046