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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.