On Tue, 2019-04-16 at 21:33 +0200, H. Nikolaus Schaller wrote:
Hi Bastien,
Am 16.04.2019 um 18:04 schrieb Bastien Nocera hadess@hadess.net: This can be done in user-space, reading the data from the IIO driver, and using uinput to feed it back. Why is doing this at the kernel level better?
Well, I'd estimate that >80% of the current kernel could be done in user-space (but not at the same speed/quality).
E.g. TCP could most likely be done by directly accessing the Ethernet layer and providing other processes access through named pipes instead of sockets.
But usually a user-space daemon feeding things back into the kernel is slower (because it is scheduled differently) and needs more resources for running the process and IPC and is less protected against hickups and deadlocks.
This is mostly irrelevant for the amount of data we're treating, but it doesn't matter too much.
Two more aspects come to my mind from reading your project page:
a) "It requires libgudev and systemd" b) "Note that a number of kernel bugs will prevent it from working correctly"
a) this makes quite significant assumptions about the user-space while a kernel driver can be kept independent of this
It's made for modern desktop OSes/"traditional" Linux. I don't think that those 2 libraries are problematic dependencies unless you're on Android, where a replacement could be implemented or iio-sensor-proxy modified for that use case.
b) if it is in-kernel it will be kept in sync with kernel changes and such bugs are less likely
No they're not. This warning was because 1) drivers sometimes have bugs 2) user-space sometimes has bugs 3) user-space sometimes causes the kernel to have bugs.
The 2 significant breakages for iio-sensor-proxy were caused by runtime PM bugs in the hid-sensor-hub driver, and in the USB core. I doubt a kernel-space implementation would have been able to magically fix those bugs unfortunately.