Closed Funky185540 closed 3 years ago
Oh and while we're at it: How exactly does Buffer::poll_fd()
work, i.e. how would I poll that FD from rust?
The Linux system calls like poll()
and epoll()
can monitor several file descriptors simultaneously and let you know when one is ready to be read or written. In the case of an IIO inout buffer, it would tell you when the buffer is ready to read (i.e. you could call refill()
without blocking).
In order to use poll()
you need a Linux file handle, wich Buffer::poll_fd()
gives you.
You would use this if you wanted to process data from multiple devices in one thread.
It's a little hacky to do this in Rust; you would need to use the nix
crate, make a slice of file descriptors, call into poll()
, and process the results. A cleaner, more modern approach would be to expose an async/await interface that used the file handles internally.
Thanks for the PR.
Hello again,
this will be the first PR in a series of different PRs that aim to add more verbose documentation to the project. It mainly grabs what documentation is available from the libiio docs, and adds it to the respective components.
I have decided to make PRs that add documentation for each individual module so I can work on them one-by-one, in separate branches, so they don't interfere. If you'd want me to change that, just tell me so.
I've marked it as WIP, because I'm hoping to get issue #13 done with this, too, by adding the tests as doctests in the examples section for each method. But in order to do that, I first have to take care of getting that iio_dummy kernel module from somewhere... I'll keep you posted on my progress.
Until then I thought I'd announce this PR so you can have a look and share your thoughts.
On a side-note, do the unsafe FFI methods return meaningful error codes, i.e. Unix or IIO specific errors? In that case I may look into wrapping the returned integer values into something more meaningful that the user can work with (and of course add documentation about that, too!).