[RFC] Thinking about extended poll support in Zephyr


Paul Sokolovsky
 

Hello,

Soon we'll need to wave bye-bye to the bloaty [1][2] k_poll(). I'm
pondering about submitting a "k_epoll" RFC some time when 1.13 heat
subsides, but just came by an article that Linux was adding yet another
advanced poll feature: https://lwn.net/Articles/743714/

So, reading thru it (and not anything else), they're not too shy to go
for complete "zero copy" by pushing poll results straight into the
userspace memory.

I personally don't think that it would affect plans for going to a
well-known epoll design, but pushing results asynchronously into the
userspace is also an interesting, if not brave, pattern we might keep
in mind trying to optimize kernel/userspace split overheads.

Btw, another point is that they not too shy to do following in the very
bloated OS:

One potential limitation built into this API is that there can only
be a single wait queue that receives notifications for a given file.
We may revisit that too, to see what are real usecases to put the same
object into multiple pollers (for a new implementation, I mean).

[1]
https://github.com/zephyrproject-rtos/zephyr/blob/master/include/kernel.h#L4411
[2]
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/lib/sockets/sockets.c#L687

--
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

Join devel@lists.zephyrproject.org to automatically receive all group messages.