Date
1 - 1 of 1
[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 onlyWe 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
|
|