From: Jonathan Cameron <jic23@cam.ac.uk>
To: Jonathan Cameron <jic23@cam.ac.uk>
Cc: linux-iio@vger.kernel.org, arnd@arndb.de,
manuel.stahl@iis.fraunhofer.de,
device-drivers-devel@blackfin.uclinux.org
Subject: Re: [RFC PATCH 0/7] IIO: Reduce to 1 the number of chrdevs per device
Date: Tue, 19 Jul 2011 09:53:41 +0100 [thread overview]
Message-ID: <4E254615.40302@cam.ac.uk> (raw)
In-Reply-To: <1310997004-22728-1-git-send-email-jic23@cam.ac.uk>
I forgot to mention that this series also thoroughly breaks the sca3000.
I'll fix that one up before reposting.
> This is another of Arnd's suggestions.
>
> Some of the patches here are just pre conversion reworks to make the important
> bit easier and some are cleanups of headers etc as a result of things not
> being needed any more.
>
> One little change I slipped in here:
>
> devices now have iio:deviceX as their name so that we have something
> sensibly named under /dev/
>
> The important patches are 4 and 6.
>
> 4 uses Arnd's suggestion of an annon_fd obtained via ioctl on the buffer
> chrdev to get a file for easy use for reading events. This is a very neat
> solution that lets us keep the actual event system separate from the data
> stream without two chrdevs.
>
> 6. Moves the remaining single chrdev so it associated with the iio_dev rather
> than the buffer. This means we now only have two types of device (other than
> weird ones like the sysfs trigger management node), triggers and devices.
> Given either can exist independently, those two don't make sense to merge.
>
> Anyhow, I'm far from convinced that the allocation / deallocation is now
> correct and that there aren't any race conditions on removal od devices.
> (then again I'm not convinced there weren't any of those before.)
>
> Note I haven't ammended the nature of either 'chrdev' at all. There
> is more to be done there.
>
> Note, this is 3.2 material so no particular rush for comments.
> Having said that, please do pull it into local trees and hammer it
> nice and hard to see where I messed up.
>
> For reference a minimal test app is:
>
> #include <stdio.h>
> /* little dirty test prog */
> #include <sys/ioctl.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <stdint.h>
>
> struct iio_event_data {
> int id;
> int64_t timestamp;
> };
>
>
> int main(int argc, char **argv)
> {
> int ret;
> int fp;
> int data;
> int i = 0;
> FILE *evfp;
> struct iio_event_data ev;
> fp = open(argv[1], O_RDONLY);
> ret = ioctl(fp, 0, &data);
> /* So we have the fd (in theory) of the anon file */
> evfp = fdopen(data, "r");
>
> if (evfp)
> for (i = 0; i < 100; i++) {
> ret = fread( &ev, sizeof(ev), 1, evfp);
> printf("%d %lld\n", ev.id, ev.timestamp);
> }
> return 0;
> }
>
> Jonathan
>
> Jonathan Cameron (7):
> staging:iio:trigger push functions that don't need to be generaly
> available down into the core.
> staging:iio:kfifo buffer - push structure definition down into
> implementation.
> staging:iio:chrdev.h rationalization.
> staging:iio: remove specific chrdev for event reading. Get fd from
> ioctl on buffer.
> staging:iio: squash chrdev handler remains into users.
> staging:iio: push the main buffer chrdev down to the top level.
> staging:iio: remove now defunct header definitions and add some
> statics
>
> drivers/staging/iio/Documentation/generic_buffer.c | 11 +-
> drivers/staging/iio/Documentation/iio_utils.h | 2 +-
> drivers/staging/iio/accel/adis16201_core.c | 6 +-
> drivers/staging/iio/accel/adis16203_core.c | 6 +-
> drivers/staging/iio/accel/adis16204_core.c | 6 +-
> drivers/staging/iio/accel/adis16209_core.c | 6 +-
> drivers/staging/iio/accel/adis16240_core.c | 6 +-
> drivers/staging/iio/accel/lis3l02dq_core.c | 6 +-
> drivers/staging/iio/accel/sca3000_core.c | 4 +-
> drivers/staging/iio/adc/ad7298_core.c | 4 +-
> drivers/staging/iio/adc/ad7476_core.c | 4 +-
> drivers/staging/iio/adc/ad7606_core.c | 4 +-
> drivers/staging/iio/adc/ad7793.c | 6 +-
> drivers/staging/iio/adc/ad7887_core.c | 4 +-
> drivers/staging/iio/adc/ad799x_core.c | 4 +-
> drivers/staging/iio/adc/max1363_core.c | 6 +-
> drivers/staging/iio/chrdev.h | 51 ----
> drivers/staging/iio/gyro/adis16260_core.c | 6 +-
> drivers/staging/iio/iio.h | 4 +-
> drivers/staging/iio/iio_core.h | 39 +++-
> drivers/staging/iio/imu/adis16400_core.c | 6 +-
> drivers/staging/iio/industrialio-core.c | 273 +++++++++++---------
> drivers/staging/iio/industrialio-ring.c | 220 ++++++-----------
> drivers/staging/iio/industrialio-trigger.c | 30 ++-
> drivers/staging/iio/kfifo_buf.c | 43 ++--
> drivers/staging/iio/kfifo_buf.h | 8 -
> drivers/staging/iio/meter/ade7758_core.c | 2 +-
> drivers/staging/iio/ring_generic.h | 28 +--
> drivers/staging/iio/ring_sw.c | 23 +--
> drivers/staging/iio/trigger.h | 39 ---
> 30 files changed, 368 insertions(+), 489 deletions(-)
>
next prev parent reply other threads:[~2011-07-19 8:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-18 13:49 [RFC PATCH 0/7] IIO: Reduce to 1 the number of chrdevs per device Jonathan Cameron
2011-07-18 13:49 ` [PATCH 1/7] staging:iio:trigger push functions that don't need to be generaly available down into the core Jonathan Cameron
2011-07-18 13:49 ` [PATCH 2/7] staging:iio:kfifo buffer - push structure definition down into implementation Jonathan Cameron
2011-07-18 13:50 ` [PATCH 3/7] staging:iio:chrdev.h rationalization Jonathan Cameron
2011-07-18 13:50 ` [PATCH 4/7] staging:iio: remove specific chrdev for event reading. Get fd from ioctl on buffer Jonathan Cameron
2011-07-21 8:57 ` Jonathan Cameron
2011-07-18 13:50 ` [PATCH 5/7] staging:iio: squash chrdev handler remains into users Jonathan Cameron
2011-07-18 13:50 ` [PATCH 6/7] staging:iio: push the main buffer chrdev down to the top level Jonathan Cameron
2011-07-18 13:50 ` [PATCH 7/7] staging:iio: remove now defunct header definitions and add some statics Jonathan Cameron
2011-07-19 8:53 ` Jonathan Cameron [this message]
2011-07-19 14:27 ` [RFC PATCH 0/7] IIO: Reduce to 1 the number of chrdevs per device Arnd Bergmann
2011-07-19 14:30 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E254615.40302@cam.ac.uk \
--to=jic23@cam.ac.uk \
--cc=arnd@arndb.de \
--cc=device-drivers-devel@blackfin.uclinux.org \
--cc=linux-iio@vger.kernel.org \
--cc=manuel.stahl@iis.fraunhofer.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox