Hi Greg, This patch set has been on linux-iio for a couple of months. The intent in IIO was always to provide a number of buffer implementations so that one could select the one that provides the features needed for a particular application. Sadly far too many drivers have become attached to ring_sw which is to put it lightly, somewhat dubious (seems to work but I wouldn't guarantee that and I wrote it). Anyhow, kfifo isn't ideal for every application, but it makes a good starting point and opens up the possiblity of other implementations. What is a sensible default for a given driver is down to the indvidual driver writers. The first patch is a spot of restructuring needed to push down some code into the sw_ring that should never have been in the core (oops). The lis3l02dq driver has been used as an example of the changes need in drivers to add support for additional buffer implementations. Final two patches are extensions of the example code. The first just allows for event less buffers (such as this one) and the second adds more arguements to make the whole example a bit more useful. The changes since V1 are all pretty trivial: * Additional help in Kconfig to illustrate when one might want to use kfifo. * Logic fix for lis3l02dq Kconfig to ensure an empty buffer menu doesn't appear when buffers are completely disabled. * Fix sparse warnings. Please consider merging. Some cleanup to the core will occur in a futures set (for example stopping creation of an event chrdev for buffers that can't produce any events). Thanks, Jonathan V1 description: This set is an update of the proof of concept I wrote a while back. This time around I've simply used a byte stream buffer rather than variable record sizes. The first patch pushes some of the exiting buffer code down into the ring_sw implementation to make it simpler to provide other implementations. What you gain by picking kfifo: * Clean fast code for the underlying buffer. What you loose: * Events - userspace has to 'know' how often to read the buffer so as to not loose data. Obvious difference is it is a fifo rather than a ring buffer. This buffer should also lend itself to a simple implementation of a store_n function which should be useful for devices with a hardware ring which we then want to feed into a software one. Jonathan Cameron (5): staging:iio:buffering move the copy to user on rip down into implementations staging:iio:kfifo buffer implementation staging:iio:lis3l02dq allow buffer implementation selection staging:iio: update example to handle case with no ring events staging:iio: buffer example - add lots more runtime parameters drivers/staging/iio/Documentation/generic_buffer.c | 63 +++++-- drivers/staging/iio/Kconfig | 9 + drivers/staging/iio/Makefile | 1 + drivers/staging/iio/accel/Kconfig | 23 +++- drivers/staging/iio/accel/lis3l02dq.h | 10 + drivers/staging/iio/accel/lis3l02dq_ring.c | 9 +- drivers/staging/iio/industrialio-ring.c | 25 +--- drivers/staging/iio/kfifo_buf.c | 196 ++++++++++++++++++++ drivers/staging/iio/kfifo_buf.h | 56 ++++++ drivers/staging/iio/ring_generic.h | 2 +- drivers/staging/iio/ring_sw.c | 27 ++- drivers/staging/iio/ring_sw.h | 4 +- 12 files changed, 366 insertions(+), 59 deletions(-) create mode 100644 drivers/staging/iio/kfifo_buf.c create mode 100644 drivers/staging/iio/kfifo_buf.h -- 1.7.3.4 -- 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