On Tue, 2019-04-16 at 21:33 +0200, H. Nikolaus Schaller wrote:

Hi Bastien,

quoted

Am 16.04.2019 um 18:04 schrieb Bastien Nocera [off-list ref]:
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.