Re: [RFC] LIBIIO

[Paul Cercueil <paul.cercueil@analog.com>]

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 <paul.cercueil@analog.com> 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
>