martinpitt
Support IIO devices
This will be useful on tablets and phones to test for accelerometers, compasses, quaternion sensors, etc.
In particular, accelerometers will behave differently if they have a "trigger" or not, if they have scan_elements, etc.
I don't seem to have an IIO hardware (at least not on my ThinkPad X230 and on my Google Nexus 4 phone), so I can't investigate for myself what's missing here.
- The
/sys/bits should certainly be ok, or is there something missing? How far do you get with detection if youumockdev-recordsuch a device and recreate it in a testbed (umockdev-run)? - Do these devices have a
/dev/node? If so, do they need any particularioctls which umockdev needs to learn? Or are these just normal char devices where you read/write from/to?
Some general info (umockdev-record dump, /dev structure, an open/read/write/ioctl/close strace what happens if some program talks to the device) would be appreciated. Thanks!
@dlech: Is that the only issue that keeps iio device emulation from working?
Probably. It doesn't use any ioctls that I know of. I haven't done anything fancy with it yet though.
Probably. It doesn't use any ioctls that I know of. I haven't done anything fancy with it yet though.
A way to manage the ring-buffers where the latest readouts are kept would be useful, but just being to instantiate the device is nice already.
No, there are no ioctls in iio. You can emulate things with a "dummy" kernel device (if you want to compile your own kernel and check things out).
I just ran into umockdev - very cool.
This would be nice to use umockdev for validation automatic test of libiio - right now it's alot of manual testing when we make a release. Since libiio uses multiple backends (local, network, usb, serial), and iiod (which serve up local IIO devices to remote applications over USB or network), getting local working would be the most useful, but we eventually use all.
Since usb looks like it is more supported - I will start with there to get familiar with umockdev.
I've managed to make it work. It's not super easy, as I didn't want to rely on the ioctl() capture and replay, as it's not great for interactive tests.
It would be great if umockdev had some helper tools for that, something that could mock /dev devices which are just fancy data buffers (and which could mock -EAGAIN too).
See https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/317
A few years ago, I did some experimenting using libfuse to provide simulated sysfs devices - mainly to simulate returning errors like that. It looked promising but I didn't get very far with it.
The SPI emulation from #125 could be a starting point now. In this case, my guess that custom code by using #132 might be better though. That can also mock -EAGAIN, it cannot mock poll state at this point though.
