On 12/17/10 20:33, Greg KH wrote: > On Fri, Dec 17, 2010 at 03:13:02PM -0500, Robin Getz wrote: >> I'm just trying to rationalise something in my head... >> >> In staging, there exists both iio, and comedi - which both seem to do similar >> things (capture/create external analog signals), just with different >> busses -- which is really different platforms (Desktop - PCI, PCIe vs >> embedded - I2C, SPI, SoC, etc). >> >> ./staging/iio >> ./staging/comedi >> >> the problem (to me) is two different userspace interfaces. >> >> For userspace, for those "typical" applications - oscilloscope, generator, >> strip chart recorder, etc - it would be nice to have a common userspace lib >> between the two - so I can prototype on a desktop via PCI DAQ card, and run >> on my embedded system with a SPI converter. > > I totally agree. > >> I can't be the only one asking if there any desire to unify these before they >> are moved to mainline (out of staging). If there isn't - that's OK too. > > There's a desire to figure out a standardized kernel/user api for these > types of devices, if they are similar. > > But, we also have to be mindful of the many years of applications that > rely on the comedi libraries. comedi has been around since the 2.0 > days, so ideally if we can keep the userspace library from having to > change its external api, we can do what we want with the kernel side. > > So, any work you might want to do in this area is most appreciated. > I have no problem with this suggestion and would be interested to see proposals of how to go about this. Be wary though, IIO also borders on two other existing subsystems, hwmon and input which could also be argued to do much the same sorts of jobs. Currently IIO provides sysfs type interfaces very similar to hwmon (the same except for with alarms where their interfaces as too restrictive) and we have shown a userspace daemon can handle conversion to input. Any proposed changes in kernel space would have to tread carefully around this. In theory one could move all the current IIO drivers over to comedi. I'd be worried about doing this for exactly the same reasons that we didn't just put these devices in input or hwmon. Some of the requirements are different (comedi was suggested as an option very soon after IIO was mooted.) That's not to say I'm anti sharing of interfaces where ever possible! Another approach would be to maintain current IIO functionality with comedi file ops along side. What bothers me about this dual approach is the additional complexity it would bring. Maybe it is worth it, but I would like to reserve judgement for now. Userspace approaches (with appropriate kernel changes) might work. Normally I'd worry about trying to do a unified library using different kernel interfaces, but given the stability of comedilib perhaps this would work. There are many elements in common and things that comedi does much better than IIO. There are definitely core elements that are similar but also differences in requirements and approach that may be hard to address. Basically I'd be interested to see proposals that move in this direction but don't yet see how it would work. Thanks, Jonathan (IIO 'maintainer') -- 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
