On 04/11/2014 18:44, Hartley Sweeten wrote:
On Tuesday, November 04, 2014 11:09 AM, Ian Abbott wrote:This series of patches adds a couple of ioctl codes to the Comedi core to allow the current "read" and "write" subdevice to be changed after opening the comedi device. The current read and write subdevice information is stored in file private data allocated for the lifetime of the file object, so the notion of current "read" and "write" subdevice is local to the file object and does not alter anything in the main control structure for the comedi device. An extra level of indirection is now required to access the main control structure. I've tested the multiple "read" subdevice case using a modified version of the "comedi_test" module (modifying it to clone the existing AI subdevice), and a modified version of the "comedi_test" application (part of the "comedilib" installation) modified to use the new ioctls. There isn't any support in comedilib itself yet. 1) staging: comedi: prepare support for per-file read and write subdevices 2) staging: comedi: add ioctls to set per-file read and write subdevice drivers/staging/comedi/comedi.h | 2 + drivers/staging/comedi/comedi_compat32.c | 2 + drivers/staging/comedi/comedi_fops.c | 217 +++++++++++++++++++++++++++---- 3 files changed, 196 insertions(+), 25 deletions(-)Ian, If I understand this correctly, the user can now open the "comediX" device which will give then access to the default dev->read_subdev and dev->write_subdev. They can then use the new ioctls to change the read/write subdevice and use them without having the open the "comediX_subdY" devices. If this is correct it seems like a good idea.
That's correct.
Reviewed-by: H Hartley Sweeten <hsweeten@xxxxxxxxxxxxxxxxxxx>
Thanks for the review!
Also, does this mean we can get rid of comedi_alloc_subdevice_minor() and the "comediX_sudbY" stuff?
That would be a bit premature at this stage. Maybe in a year or two. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@xxxxxxxxx> )=- -=( Web: http://www.mev.co.uk/ )=- _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
