Dear Alan, >> have both functions. The sort of devices we are talking typically >> communicate over I2C or SPI buses though drivers for rs232 devices etc are >> definitely on the cards. Basically we are interested in devices where direct >> memory mapped access is not possible. > > We have I2C and SPI drivers so I assume you will use the lower layers of > the stacks to do this ? Yes, in much the same way that for example hwmon is built on top of these (amongst other interfaces) > >> For discussion of why these don't fit within existing subsystems see >> http://lkml.org/lkml/2008/5/20/135 and the rest of the associated thread. > I don't see much there which says why you can't unify all this in a user > space library. Indeed, that was an option considered at the time and the majority of that discussion focused on how to do things in a similar way to existing similar kernel subsystems. Perhaps this question needs further clarification. Much of the stuff provided in this initial patch set could indeed be provided by a fairly complex user space library. I get the feeling this rest of this response is going to look pretty familiar. Though as I have never attempted to code anything other than simple userspace drivers I suspect others may have more detailed responses. These are in no particular order. I believe the principle argument in favour of user space drivers is that of enhanced stability as they are unlikely to be able to bring the kernel down. This advantage is indeed valid here. The other advantage is that the number of copies required to get data to and from hardware are reduced. For the devices considered here a userspace driver would have to go via one of the chrdev interfaces and neither i2c-dev or spidev are able to support mmap ed interfaces. The problems I can forsee (or have encountered) with user space drivers for this sort of device: * In many cases the ADCs form part of more complex devices which already have a support within the kernel. (e.g. PMICs such as those supported by the DA903x mfd driver) and as such any additional interface will require at least some kernel parts. Other places I've seen ADCs that I'd like to have available via a consistent interface, include firewire and usb cameras (aux ADC's and DAC's are common for controlling pan tilt heads etc). Some of these could be implemented in userspace (and quite possibly should be,) but others would require driver changes that will effectively equal those of adding direct support for the subsystem described in these patches. * Spidev and i2cdev are fairly restricted interfaces which I have used extensively for initial investigation of sensors. The key thing here is that almost no devices use purely these interfaces. They include interrupt lines etc requiring relatively complex handlers. Thus any driver would probably require at least some kernel space element per chip anyway. Also worth noting that this tends to be the most complex and hence probably error prone part of these drivers. The spidev documentation talks about the limitations of the driver. An example of the problems that would be encountered with the current i2c-dev implementation within a full driver would be a control register read on a VTI SCA3000 (i2c) accelerometer. This would require an initial 3 byte write followed by a 1 byte read. In kernel space this whole thing can be set up in a dma capable buffer and done in one go with copies out to userspace only needed if the value is meant to be read by the user. * Need to provide kernel space interfaces. This actually fulls under the RFC question of what the scope of this subsystem should be. For example, things like battery chargers, free fall detectors etc frequently use generic components of the types that IIO will include. The systems that use these sometimes require kernel level access which a userspace driver clearly cannot supply. * Performance: Thinks like time stamping of data ready signals needs to be as near as possible to the source interrupt. As for the complex question of which is optimal for the ring buffering functionality, this would need thorough optimization of both approaches before it could be addressed. I'm not aware of any similar comparisons but would be grateful if anyone could direct me to any they know of. It is also worth noting here that many applications that will use the ring buffered interface will never actually read the contents of the buffer as they are interested in only restricted regions of data (based on some external trigger). In conclusion, I'd be interested in the long run in the possibility of moving all the above functionality into userspace but at the moment don't believe it to be the sensible option here. The alternative of would be to provide only those drivers that would benefit from a kernel space driver within this subsystem. This would lose the advantages to be gained from a consistent interface. This could in turn be made transparent via a userspace library but only at the cost of unnecessary complexity. > > For RS232/423/.. devices you can go this path if you want (but I would > keep it all in userspace anyway) as you can use a line discipline to sit > on top of the port and provide another interface (eg the way PPP does) An interesting suggestion. The main reason I'd be interested in bringing these into the kernel is to do with the handling of additional interrupt lines (which a number of similar devices have). Thanks for the comments, -- Jonathan Cameron
