Messages in this thread | | | Subject | Re: [RFC v3] iio: input-bridge: optionally bridge iio acceleometers to create a /dev/input interface | From | Bastien Nocera <> | Date | Fri, 10 May 2019 10:56:55 +0200 |
| |
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.
| |