On Wed, 2014-10-29 at 18:39 +0100, Lars-Peter Clausen wrote: > On 10/29/2014 06:33 PM, Bastien Nocera wrote: > > On Wed, 2014-10-29 at 18:21 +0100, Lars-Peter Clausen wrote: > >> On 10/29/2014 03:30 PM, Bastien Nocera wrote: > >>> Hey, > >>> > >>> I've posted this a couple of days ago: > >>> http://www.hadess.net/2014/10/a-gnome-kernel-wishlist.html > >>> along with a mail to LKML: > >>> http://thread.gmane.org/gmane.linux.kernel/1810083 > >>> > >>> I've recently added to my list an item about IIO: > >>> https://wiki.gnome.org/BastienNocera/KernelWishlist > >>> > >>> Are there any plans for a better API for the IIO subsystem? The API > >>> might be good enough to drive from shell scripts, or helpers that only > >>> need to work with one variant of a device, but my attempts at trying to > >>> use the IIO subsystem to provide an accelerometer to do automatic > >>> display rotation[1] showed that the API is really cumbersome. > >>> > >>> The code I wrote spends most of its time creating sysfs paths, reading > >>> values in different formats, and mangling filenames[2]. > >>> > >>> Is an ioctl-based API planned? Something where I could get/set > >>> structures to gather metadata about the device, and set it up easily, so > >>> reading data from it is easier? > >> > >> No, unfortunately not and I'm not sure if such a ABI would be accepted if > >> proposed. > > > > Why not? > > Because it means there will be ambiguity in the API on how to do things. > Which is typically not a desired property. > > > > >> But checkout libiio[1][2], it hides the details of the sysfs file manipulation. > > > > I'm not sure that's any better unfortunately. I've certainly tried to do > > that already in my code, but that doesn't change that the user-space API > > is barely usable. > > It's not completely unusable ;) In the end, you prefer the "self-documenting" of using sysfs files, rather than an API which you can document in a header file? I don't understand that. My questions on this very mailing-list, and comments that were made to users of my code[1] clearly show that the existing API is anything but "not ambiguous". I've used the Bluetooth, input, rfkill, and inotify APIs as provided directly by the Linux kernel (not through a layer) and they're of better quality than the IIO one. I just don't see how one could support a class of IIO sensors with the existing API. Cheers [1]: https://github.com/hadess/iio-sensor-proxy/issues/1#issuecomment-54536393 -- 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
