From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tx2ehsobe003.messaging.microsoft.com ([65.55.88.13]:43473 "EHLO tx2outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750829AbaCFJAR (ORCPT ); Thu, 6 Mar 2014 04:00:17 -0500 Message-ID: <531838D8.2050608@analog.com> Date: Thu, 6 Mar 2014 09:59:04 +0100 From: Paul Cercueil MIME-Version: 1.0 To: Jonathan Cameron CC: Subject: Re: [RFC] LIBIIO References: <53146822.5020602@analog.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Sender: linux-iio-owner@vger.kernel.org List-Id: linux-iio@vger.kernel.org Hi Jonathan, About function naming, my convention is to name the API functions after the structure they work with: iio_device_* accept a iio_device structure, iio_channel_* accept a iio_channel, iio_context_* accept a iio_context. In that logic, the create functions are not passed a iio_context, so they are not named with the same pattern. However, I really don't mind to change that if you think having them named iio_context_create_* would be better. About attributes sharing, what you describe is already implemented, just not for all device attributes. Given the following sysfs files: in_magn_scale in_magn_x_raw in_magn_y_raw in_magn_z_raw the local backend of the library will detect that 'in_magn_scale' is a device attribute that should be shared between all input channels named 'magn[0-9]+' or 'magn_{modifier}'. For the 'sampling_frequency' attribute, the library has no way to tell whether or not it applies to the channels, and so it is left as a device attribute. Thanks for your comments! Paul On 03/05/2014 06:29 PM, Jonathan Cameron wrote: > Hi Paul > > Looks good. I will have a more detailed look at some point. > > Just been browsing headers. One trivial point... > Try to keep function naming consistent. > I would expect create functions to be named like > > iio_context_xml_create etc rather than iio_create... > > Your destroy etc are that way around. Note I actually had a similar mess in early kernel iio interfaces :) > > I haven't look in detail but it would be nice to hide some of the complexity of attribute > sharing so if someone queries sampling frequency for a channel, the fact it is > specified for a device is hidden. This might involve one attr appearing in multiple places in your hierarchy. Is this something you > would consider? Write semantics are more complex though. > Also beware that according to the abi, any write to an attribute can change any other > attribute (there are sanity restrictions though) > > Just quick thoughts! Sorry for top posting:) > > Jonathan > > > On March 3, 2014 11:31:46 AM GMT+00:00, Paul Cercueil wrote: >> Hi there, >> >> I would like to present the project I've been working on for the past >> two weeks: libiio, a library for interfacing IIO devices. >> Available here: https://github.com/analogdevicesinc/libiio >> >> As it is still in its infancy, I would like to receive feedback about >> the API, what is good, what would you change etc. >> >> The API provides a couple of top-level functions to create a context, >> either bound to the local IIO devices through sysfs, to a XML >> representation, or to a remote server. This context structure (struct >> iio_context) contains a list of devices and the context-specific >> low-level operations to interact with them. >> >> From the context structure it is possible to retrieve the structures >> representing the devices (struct iio_device). Devices have an ID, a >> name, attributes and channels. >> >> Attributes essentially correspond to files in sysfs. For instance, the >> attribute "sampling_frequency" of the device with the ID "iio:device0" >> matches the file "/sys/bus/iio/devices/iio:device0/sampling_frequency". >> The API provides functions to read or write attributes. >> >> Channels (struct iio_channel) represent a measure channel of a ADC or a >> >> control channel of an DAC. In the local context, the channels are >> deduced from the filenames in sysfs. For example, the file >> "out_voltage0_vccout_offset" translates to an output channel with ID >> "voltage0", name "vccout" featuring an attribute named "offset". >> >> The following sysfs files, for instance, would create the following >> tree: >> >> root:/> ls -1 -p /sys/bus/iio/devices/iio:device0 >> buffer/ >> dev >> ... >> in_magn_filter_low_pass_3db_frequency >> in_magn_scale >> in_magn_x_raw >> in_magn_y_raw >> in_magn_z_raw >> name >> power/ >> sampling_frequency >> scan_elements/ >> subsystem >> trigger/ >> uevent >> >> --- >> >> IIO context has 1 devices: >> iio:device0: adis16488 >> 11 channels found: >> ... >> magn_x: (input) >> 4 channel-specific attributes found: >> attr 0: calibbias >> attr 1: filter_low_pass_3db_frequency >> attr 2: raw >> attr 3: scale >> magn_y: (input) >> 4 channel-specific attributes found: >> attr 0: calibbias >> attr 1: filter_low_pass_3db_frequency >> attr 2: raw >> attr 3: scale >> magn_z: (input) >> 4 channel-specific attributes found: >> attr 0: calibbias >> attr 1: filter_low_pass_3db_frequency >> attr 2: raw >> attr 3: scale >> 1 device-specific attributes found: >> attr 0: sampling_frequency >> >> --- >> >> The API provides ways to read and write a stream of values. Either the >> raw stream (basically reading/writing the dev node directly), or a >> processed stream, corresponding to a single channel, with an optional >> conversion step. In this case, the conversion is automatically deduced >>from the attributes, notably the "scale" attribute. >> >> One recurring issue when working with IIO devices, is that only one >> application can use an IIO device at a time. I intend to address that >> issue by developping a network daemon (called iiod, that's original) >> that would use the local backend of the libiio library, and stream the >> data from/to a device from/to all of its connected clients. The clients >> >> would then just be applications compiled with the libiio library, and >> using the network backend of the library (note that switching between >> backends is just a matter of creating the iio_context structure with a >> different function). Once that works, a specific daemon / libiio >> backend >> couple could be designed using fast SHM mechanism for high-speed >> concurrent local access to the devices. >> >> As I may be overseeing certain things or missing others, I would like >> to >> know what is your opinion of the API and the library so far, and if you >> >> would use such a library. The feedback is important to me so that the >> project moves in the right direction. >> >> Thanks, >> >> Paul >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >