[Genivi-ipc] Setting bus type

Konopelko, Pavel (P.) pkonopel at visteon.com
Wed Jun 1 05:58:17 EDT 2016


Karlsson, Johnny wrote on 2016-05-31:
> I was looking thru the discussion below and I'm wondering if there has
> been any work done in getting "bus type" support for the generator
> tools? Or is the status "patches are welcome"?

As far as I can tell, CAPIC++ 3.1.5 supports specifying DBusBusType via the deployment specification [1] (as well as via the configuration file).  What kind of support for the generator tools are you referring to?

--Pavel Konopelko

[1] http://git.projects.genivi.org/?p=ipc/common-api-dbus-tools.git;a=blob;f=org.genivi.commonapi.dbus/deployment/CommonAPI-DBus_deployment_spec.fdepl;h=a9b12e7b32ab2e1183a73f8ec2df278e2917fe02;hb=HEAD

> ________________________________________
> From: genivi-ipc-bounces at lists.genivi.org <genivi-ipc-
> bounces at lists.genivi.org> on behalf of Uhl, Klaus <klaus.uhl at intel.com>
> Sent: Friday, April 15, 2016 11:35:35 AM
> To: genivi-ipc at lists.genivi.org
> Subject: Re: [Genivi-ipc] Setting bus type
> Hi Pawel,
> genivi-ipc-bounces at lists.genivi.org wrote on 2016-04-14:
>> Gunnar,
>> Andersson, Gunnar wrote on 2016-04-14:
>> [...]
>>> I've been discussing this definition of which bus you want to use with
>>> some colleagues earlier.   They're too busy to write about it I think.
>>> We think it should be a deployment model thing, to specify which bus
>>> should be used?  Shouldn't it?
>>> A separate ini-file doesn't feel really clean - this info relates to
>>> the Franca interfaces, but is still some other independent file.
>> Deployment files are about build-time configuration.  INI-files are
> about
> run-
>> time configuration.  Both are equally useful.
> Although I agree with you in principle, I still think that a component
> should be able to run without - or at least with minimal - runtime
> configuration whenever possible. Or to put it the other way around:
> whatever can be compiled into a component as a meaningful default should
> be compiled in. Being able to override the compiled in defaults should
> be an add-on feature. Otherwise, you have to leave it to the
> documentation and the component user to get the default configuration
> right. And this will often break.
> Coming back to the initial problem of configuring the DBus bus type this
> would mean for me that each component which is intended to communicate
> via the system bus should have this configuration compiled in as a
> default.
>>> And in addition to that, if I understand correctly, you actually have
>>> to know how the generators translate Franca names into DBus names?
>>> And that "_instance" word just hangs there.  Why would you want that
>>> to be part of the translation in the case there is only one instance.
>>> If you need to know the translation of the names (and as I indicate
>>> above it sounds like we might want to modify the logic for how that is
>>> done) then it really isn't very clean.  That's not something you
>>> should have to know really, IMHO.
>> CAPIC++ uses transport-independent instance addresses in form of
>> triples <domain, interface, instance>.  In case of D-Bus, default
>> service
> names
> are
>> created by concatenating the interface and the instance names with an
>> underscore in between.  In my example, the instance name was specified
>> as "instance" and that resulted into "_instance" suffix.  Configuration
>> (and possibly deployment files) can specify explicit translation of
>> instance addresses into the terms specific for a particular transport
>> like D-
> Bus.
> The override mechanism of CAPIC++ DBus is particularly useful for
> CAPIC++ based components that have to communicate with other DBus
> components that are not using CAPIC++. In those cases CAPIC++'s default
> mapping will very likely not match the other component's configuration.
> If both sides of the communication are implemented using CAPIC++ then
> overriding the mapping is not required.
> Kind regards
> Klaus
> 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 _______________________________________________
> genivi-ipc mailing list genivi-ipc at lists.genivi.org
> https://lists.genivi.org/mailman/listinfo/genivi-ipc

More information about the genivi-ipc mailing list