Dear All, We recently proposed an API specification for parts of the Industrial I/O subsystem in a thread on LKML. Greg KH pointed out that a we ought to, where sensible keep as close as possible to API's of existing subsystems. To that end we are working on an updated version of the original document. (original at http://lkml.org/lkml/2010/1/20/195, please note it has changed a lot in response to comments made in that thread!) The big difference from hwmon is that we very rarely export processed values to user space. The fundamental reason for this is that our primary access to data is via ring buffer interfaces accessed through related character devices rather than direct access through sysfs. Speed is of the essence and often processed values are not actually what is required in any case. However, we do wish to provide sufficient information for a user space library to perform these calculations in the common case of a linear transform. Anyhow, taking just voltage channels (ADC's) as a starting point we are looking at the following and would appreciate comments / suggestions from the hwmon community. in0_raw //raw access in0_offset in0_gain (in0_value equivalent would be obtained from (in0_raw + in0_offset)*in0_gain) In cases where all channels of type in share offset and gain we also allow (to reduce the large number identical sysfs entries): in_offset in_gain There are a couple of cases that I'm not sure how to sensibly handle, particularly differential pairs. Here we want to indicate which input lines they refer to within the name and that we are dealing with a differential situation. Ideas that come to mind for a case which is corresponds to (in0_raw - in1_raw) are in0:1_raw diff0:1_raw in0-1_raw What do people think is clearest? Obvious, as per hwmon the vast majority of users are going to access this through a user space library, but it would still be nice to get a sensible human readable layout in sysfs. Also note that there are a number of other elements associated with each channel, but I have left them out of this discussion to keep things simple (for now!) They are primarily to do with the ring buffer access and so do not overlap so much with hwmon other than in base naming of channels. Note that there is no intention of adding the option to use these new interfaces to hwmon, merely an intent to avoid introducing incompatible interfaces should this functionality become of interest in the future and to take advantage of the experience of the developers on this list. Thanks, Jonathan Cameron p.s. I've thinned out the original list of ccs to those interested in this aspect. Please forward to any interested parties whom I have missed! _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
