On Thursday 16 June 2011, Jonathan Cameron wrote: > Obvious options (or ones that have been suggested) > > * Use out of band signalling on the main data chrdev. Basically poll with the more > unusual types, POLLPRI perhaps. Then use an IOCTL to read what actually happened. > (grep suggests it gets used for something similar in v4l2-subdev.c) (suggested by > Arnd Bergmann). The important change that I'd really like to see is the use of poll() to wait for events. Using POLLPRI/ioctl to get IIO events is particularly nice IMHO because it lets you represent every IIO device as a single chardev. However, using a separate file descriptor (chardev or something else) with POLLIN/read is also totally fine. An interesting twist would be an ioctl on the chardev that returns a new file descriptor (from anon_inode_getfd()) on which you then do poll/read to get the events, instead of having separate character devices. > * Similar system to evdev in input. This carries a few extra fields, but that probably > doesn't matter. We need to know when an event happened reasonably soon after, but not > asap. I'd suggest that if you do something similar to evdev, then make it use the *exact* same user interface with the ioctl command definitions used in evdev. One disadvantage that I see here is that the evdev interface has a number of flaws regarding is 32 bit compatibility code that you cannot solve in a backwards-compatible way. Another is its use of variable-length ioctl arguments, which I would recommend avoiding in general. Also, Adding evdev extensions for iio into linux/input.h might be seen as a layer violation by interface purists. > * Separate evdev from input and share it across both subsystems. This seemed like > a good idea, but evdev is pretty tightly tied to the input core. Note we would never > be sharing input's event codes. They are too restrictive (with good reason seeing > as they are for 'input' devices!) Basically I expect this could be done, but would > need to be done very carefully so as to not have any impact on input users. Perhaps > it is the right answer, but its not trivial. (I've cc'd linux-input to get comments > on this option!) This could be a second step if you decide to use the evdev interface. You start by duplicating evdev functionality within IIO at first, and then at a convenient time you put the common parts into a library module that is used by both input and iio for evdev. > * Some other event passing methods that I've either forgotten or never knew about > in the first place. For completeness, the list should probably include generic netlink sockets (net/netlink/genetlink.c). Some people hate them, others love them. They certainly fit the requirements and have some other nice properties, so I'd suggest you read some documentation and examples and build your own opinion. > * Leave things be. Its small and simple. Perhaps it's best we don't try to be clever > at all. I would really hope for the interface to change to allow poll. The least invasive option would be to simply add a poll() function to iio_event_chrdev_fileops, which allows you to wait for multiple events in a single thread. Anything beyond that is an option IMHO. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html