{"action":"created","issue":{"url":"https://api.github.com/repos/analogdevicesinc/libiio/issues/9","labels_url":"https://api.github.com/repos/analogdevicesinc/libiio/issues/9/labels{/name}","comments_url":"https://api.github.com/repos/analogdevicesinc/libiio/issues/9/comments","events_url":"https://api.github.com/repos/analogdevicesinc/libiio/issues/9/events","html_url":"https://github.com/analogdevicesinc/libiio/pull/9","id":65690895,"number":9,"title":"Dev plugins support upstream submit 01 branch","user":{"login":"ncarrier","id":1198750,"avatar_url":"https://avatars.githubusercontent.com/u/1198750?v=3","gravatar_id":"","url":"https://api.github.com/users/ncarrier","html_url":"https://github.com/ncarrier","followers_url":"https://api.github.com/users/ncarrier/followers","following_url":"https://api.github.com/users/ncarrier/following{/other_user}","gists_url":"https://api.github.com/users/ncarrier/gists{/gist_id}","starred_url":"https://api.github.com/users/ncarrier/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ncarrier/subscriptions","organizations_url":"https://api.github.com/users/ncarrier/orgs","repos_url":"https://api.github.com/users/ncarrier/repos","events_url":"https://api.github.com/users/ncarrier/events{/privacy}","received_events_url":"https://api.github.com/users/ncarrier/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2015-04-01T13:59:43Z","updated_at":"2015-04-07T13:18:18Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/analogdevicesinc/libiio/pulls/9","html_url":"https://github.com/analogdevicesinc/libiio/pull/9","diff_url":"https://github.com/analogdevicesinc/libiio/pull/9.diff","patch_url":"https://github.com/analogdevicesinc/libiio/pull/9.patch"},"body":"Hello,\r\nHere is a patch set which implements plugins support for libiio.\r\n\r\nThe main goal is to allow implementing libiio backends outside of libiio, in plugin form.\r\n\r\nThe base idea is that a given directory is scanned for .so files, whose name match a given pattern.\r\nThese .so are dlopened and have access to some functions from the internal libiio API (from iio-private.h and debug.h).\r\nFor the particular case of backend implementation, two functions are provided, allowing plugins to register context factories, iio_context_factory_register() and iio_context_factory_unregister().\r\nA factory allows the creation of an iio_context, parametrized with key/value string properties.\r\nThe local and network plugins are modified to register factories and their context creation function wrappers in context.c are modified to use these factories.\r\n\r\nA public API function is added, to allow the access to an arbitrary backend implementation: iio_create_context().\r\n\r\nThe main drawback I see of this patch set is that it may break libiio on windows. Since I have absolutely no knowledge of this platform, I'm not competent for fixing that issue. I hope some more knowledgeable people will be able to do it. Maybe a conditional compilation approach, disabling the feature in non-dlopen capable platform would be a correct first attempt.\r\n\r\nHaving the possibility to create custom backends would allow a lot of possibilities, for example :\r\n\r\n * record sensors/actuators accesses at runtime without altering the normal functioning of the upper software (and without using a network daemon)\r\n * inject fake data from either a record file or a simulated environment\r\n * access via libiio, sensors not using the kernel iio framework, i.e. add iio support in userland.\r\n * enable any of the previous possibility, at runtime, with no recompilation\r\n\r\nI am open to any suggestion or remark."},"comment":{"url":"https://api.github.com/repos/analogdevicesinc/libiio/issues/comments/90547797","html_url":"https://github.com/analogdevicesinc/libiio/pull/9#issuecomment-90547797","issue_url":"https://api.github.com/repos/analogdevicesinc/libiio/issues/9","id":90547797,"user":{"login":"pcercuei","id":403272,"avatar_url":"https://avatars.githubusercontent.com/u/403272?v=3","gravatar_id":"","url":"https://api.github.com/users/pcercuei","html_url":"https://github.com/pcercuei","followers_url":"https://api.github.com/users/pcercuei/followers","following_url":"https://api.github.com/users/pcercuei/following{/other_user}","gists_url":"https://api.github.com/users/pcercuei/gists{/gist_id}","starred_url":"https://api.github.com/users/pcercuei/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pcercuei/subscriptions","organizations_url":"https://api.github.com/users/pcercuei/orgs","repos_url":"https://api.github.com/users/pcercuei/repos","events_url":"https://api.github.com/users/pcercuei/events{/privacy}","received_events_url":"https://api.github.com/users/pcercuei/received_events","type":"User","site_admin":false},"created_at":"2015-04-07T13:18:17Z","updated_at":"2015-04-07T13:18:17Z","body":"Hi,\r\n\r\nThe struct iio_backend_ops should be visible to the plug-ins, that's certain.\r\n\r\nThe callbacks, on the other hand, should resort to use the public API as much as possible. I don't think that it would be hard to do; most of the fields of the iio_* structures defined in \"iio-private.h\" can already be retrieved using API functions. Some fields cannot (e.g. device->ctx or channel->dev have no equivalent API function), but it would make sense to have API functions for those as well. \r\n\r\nFor the iio_[context|device|channel]_pdata, we could just have public accessors à la iio_device_get_data / iio_device_set_data, not part of the public API and defined in a separate header (e.g. iio-backend.h) reserved for the backend implementations.\r\n\r\nFrom my experience, the network backend could very well be using the public API of libiio (with the few additions listed above); the main reason why it currently doesn't, is because it is faster to type ```chn->id``` than ```iio_channel_get_id(chn)``` :)\r\n\r\nThe local backend uses the internals much more as it does all the work of creating the IIO context from what it sees in sysfs. It would be possible though to simplify it enough so that it only uses API functions and backend-specific functions, by making it generate XML from what it sees in sysfs, and use the XML backend to create all the structures. The XML backend, in that case, would be the only one built into the library and the only one with a full visibility on the internals.\r\n\r\nI can work on de-coupling the local backend from the core of the library once we have a well-defined API; for now I think we can keep it built-in. Having the network backend decoupled, on the other hand, seems a good way to test the robustness of the plug-in implementation.\r\n\r\nPaul"}}