Message-Id: <201106161327.57015.arnd@arndb.de>
Date:	Thu, 16 Jun 2011 13:27:56 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Jonathan Cameron <jic23@....ac.uk>
Cc:	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"Hennerich, Michael" <Michael.Hennerich@...log.com>,
	Manuel Stahl <manuel.stahl@....fraunhofer.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>
Subject: Re: RFC: IIO: Options for 'event' userspace interface.

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists