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@xxxxxxxxxx>: > > 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.
