[Genivi-ipc] Setting bus type

Konopelko, Pavel (P.) pkonopel at visteon.com
Wed Jun 1 06:48:00 EDT 2016


Johnny,

Karlsson, Johnny wrote on 2016-06-01:
> That the common-api-dbus-generator which uses the .fdepl files actually
> outputs code which support selections of bus typ. I have used the ini-
> files but that doesn't really scale in larger projects.

I didn't realize that this doesn't work--thanks for clarifying.  I guess this bug is already tracked [2].

@Juergen:
Do you guys have something in the pipeline already to fix [2]?


Thanks,
--Pavel Konopelko

[2] http://bugs.genivi.org/show_bug.cgi?id=404

> ________________________________________
> From: Konopelko, Pavel (P.) <pkonopel at visteon.com>
> Sent: Wednesday, June 1, 2016 11:58:17 AM
> To: Karlsson, Johnny
> Cc: genivi-ipc at lists.genivi.org
> Subject: RE: Setting bus type
> 
> Johnny,
> 
> 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?
> 
> 
> Regards,
> --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
> 
> 
> _______________________________________________
> 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