[Genivi-ipc] CommonAPI3 + SOME/IP: Return of experience

Uhl, Klaus klaus.uhl at intel.com
Thu Aug 13 08:54:05 UTC 2015


Hi Frederico,

having implemented a custom CommonAPI IPC binding I have also learned
a bit or two about the internal workings of CommonAPI.

> -----Original Message-----
> From: genivi-ipc-bounces at lists.genivi.org [mailto:genivi-ipc-
> bounces at lists.genivi.org] On Behalf Of Frederico Cadete
> Sent: Thursday, August 13, 2015 10:20 AM
> To: genivi-ipc at lists.genivi.org
> Subject: [Genivi-ipc] CommonAPI3 + SOME/IP: Return of experience
> 
> Hello,
> 
> At AWTCE we have just tried the recently released CommonAPI3 with
> SomeIP support.
> We had already used CommonAPI version 2, but we still faced a few issues
> with the new setup. Maybe they are fixable, or this mesasge can serve as a
> forewarning to future users. They are anyway easier issues than those that
> would be faced with independent development. Thank you very much for
> sharing these components.
> 
> 1 - Computation of library name not compatible with library versioning
>     The commonapi.ini config file can include a definition of a library name
>     to handle a specific binding.
>     The code in CommonAPI/Runtime.cpp:loadLibrary() will always append
> ".so" to
>     the library name if it does not already end in ".so". But using Yocto and
>     following Unix convention for library versioning, on a production filesystem
>     the files will be named "libsomething.so.1.0.0" or similar. The current code
>     would look for "libsomething.so.1.0.0.so", which does not exist in a rootfs
>     with sane names.
>     We have a patch available for this issue, applied on common-api-runtime.

There is no strict requirement that you have to use the dynamic loading of IPC
bindings. You can always directly link them into your executable which would
completely eliminate your problem. We are only using this approach because
you can make sure at link time that the abstraction layer and IPC binding
classes really match. If you are using the dynamic loading approach you have
to ensure that during system integration.

Apart from that, I would consider those shared libraries as plug-ins, not libraries
in the classical sense. And at least we are building plug-ins without the version
suffix (executables don't have that either). I do not know if Yocto can handle
plug-ins in this way but it may be a topic you might want to look into.

> 2 - Documentation mistakes in environment variable for config file
>     The config file commonapi.ini or commonapi-someip.ini can be found in
> default
>     locations or in a location specified by an environment variable.
>     Unfortunately, the documentation says it should have the path to a
> directory
>     but the code expects it to be the full filename. Also, the variable's name
>     for the someip file does not match exactly between the documentation
> and
>     the code.
>     We also have patches that fix this documentation, applied on common-api-
> tools
>     and cpp-someip-tools.
>
> 3 - Error handling
>     In some areas of the code it can be difficult to track down the root cause
>     when there is a system-level issue. For example, if in the commonapi-
> someip.ini
>     file we write "Instance" instead of "instance", then buildProxy() will return
>     NULL. No error message or exception is output to the log. It may be helpful
>     to do this when handling external input like configuration files.

What you are describing here is, actually, the result of a much more fundamental
limitation of the initialization API in CommonAPI::Runtime. We have run into the
same weird behavior (and incomprehensible log messages) when our custom IPC
binding was not able to correctly initialize an adapter. I have filed a defect that
covers this: http://bugs.genivi.org/show_bug.cgi?id=379

> 4 - Issue with network bring-up
>     Our application that plays the role of client is started very early in the
>     boot process. It actually starts before the configuration of the network
>     interface is complete. This leads to an error in a call to setsockopt() by
>     the vsomeip code. This code dutyfully prints an [error] message to the log,
>     but the call from the application to buildProxy() still succeeds.
>     Subsequently, calls to proxy.isAvailable() return false. Even when the
>     network becomes configured, they still return false.
>     I may investigate further in the near future.
>     Ultimately this issue can be avoided at the application or systemd level by
>     waiting for the network configuration, but a more consistent error or
> better
>     recovery from the IPC stack would be helpful. Especially given the next
> issue...
> 
> 5 - Can't reset CommonAPI context
>     Maybe I missed something from the documentation or I'm understanding
> the code
>     incorrectly... But I can't find a way to reset the CommonAPI context apart
>     from restarting the full process. Runtime::get() initializes and returns
>     a singleton object, and there seems to be no way of reverting or resetting
>     it. A similar thing happens with buildProxy(); there is no destroyProxy(),
>     and AFAICT removing the reference to the returned shared_ptr
>     does not destroy the underlying object. Ultimately this prevented me from
>     bringing back the process to a healthy state when issue 4 surfaced.

I have a quite different view on this. In my opinion, both 4) and 5) are limitations
of the IPC binding implementation. What you are describing should be handled in
there. There should not be any need for the component code itself to trigger the
re-initialization of anything IPC related. The proxy API already contains the proxy
status event which should inform the application about the loss and reestablishing
of communication. Maybe something similar should also be added to the stub API.

> 6 - CommonAPI versions not parallel installable
>     This is more a packaging issue than the actual code. Using the Yocto recipes
>     from meta-ivi, the commonapi headers are installed to
> /usr/include/CommonAPI.
>     In our system, we wanted to use CommonAPI 2 for one service and
>     CommonAPI 3 for another service (and my feeling is it is not that
> uncommon for this
>     to happen). With this naming, they can't both be installed in the sysroot or
>      in the rootfs.
>     It's easy enough to fix: we edited the build files to add the major version
>     to the install paths, similar to GNOME's recommended scheme [1]
> 
> And that's about it. After identifiying and fixing or working around these
> issues, the setup worked as advertised. We did find it very useful to have the
> same API for local or remote IPCs.
> 
> For the patches we have for issues 1 and 2, would the maintainers prefer
> them on bugzilla or mailing list?
> Is there a bugzilla for the someip components?
> We can also share our Yocto recipes for vsomeip, cpp-someip* and for
> common-api* version 3, if anyone is interested.
> 
> [1] https://developer.gnome.org/programming-
> guidelines/unstable/parallel-installability.html.en
> 
> Best regards,
> Frederico
> 
> Frederico Cadete
> Software Engineer
> AWTC Europe www.awtce.be

Kind regards
Klaus

Internet Of Things Group
Dr.-Ing. Klaus Uhl
Senior Embedded Software Engineer | IOTG Transportation Solutions Division TSD
Automotive Innovation & Product Development Center
Intel Corp. | Emmy-Noether-Str. 9 | Technologiepark | D-76131 Karlsruhe | Germany
Tel: +49 (0)721 6269 5271 | Email: klaus.uhl at intel.com
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Prof. Dr. Hermann Eul
Chairperson of the Supervisory Board: Tiffany Doon Silva
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928



More information about the genivi-ipc mailing list