On 01/25/2014 08:18 PM, Rees, Kevron wrote:
> Right now I see a couple of services like murphyd and connman on the
> bus...  But automotive-message-broker (ambd) isn't able to get on the
> bus because of a "permission denied" issue.  If I have kdbus running
> correctly, should I be seeing that some services are running or should
> all services fail?

There is no simple answer for that question.

You can check if there is /dev/kdbus/0-system/bus device node - if
it's there that means systemd has created it and is managing system
bus.

You can now check what services are available using

  busctl --system

root:/tmp> busctl
NAME                                   PID PROCESS         USER             CONN
:1.1                                     1 systemd         root             :1.1
:1.101                                 323 systemd         root             :1.1
:1.2                                    54 systemd-network root             :1.2
:1.42                                  135 systemd-logind  root             :1.4
:1.4372                              11163 busctl          root             :1.4
:1.78                                  209 systemd         app              :1.7
fi.epitest.hostap.WPASupplicant          - -               -                (act
fi.w1.wpa_supplicant1                    - -               -                (act
net.netconfig                            - -               -                (act
org.bluez                                - -               -                (act
org.download-provider                    - -               -                (act
org.freedesktop.DBus                     - -               -                (act
org.freedesktop.PolicyKit1               - -               -                (act
org.freedesktop.UDisks2                  - -               -                (act
...

Note that processes that actually successfully registered on bus
can be seen with non-empty PROCESS column.  These with dash (-)
will be auto-activated - which may, but might not, succeed.

Cheers,
Karol


> 
> On Fri, Jan 24, 2014 at 4:05 PM, Karol Lewandowski <[email protected]> wrote:
>> (OP from private address here.)
>>
>> On Fri, 24 Jan 2014 12:56:42 -0800, Rees, Kevron wrote:
>>
>>> FYI, while trying to gbs build the kdbus-bus from the kdbus-integration
>>> branch I get:
>>>
>>> error: Invalid upstream treeish upstream/0.5
>>>
>>> Looks like we are missing a tag.
>>
>> Interesting.  It didn't fail for me as I didn't have upstream
>> branch checked out at all.
>>
>> I could add this tag, but there is no such thing as upstream's
>> version 0.5 (or any other).  What we have is just git sha1.
>>
>> I could create upstream/gitXXXXXX tag, and (possibly) use this
>> as a version.  That would be better on one hand, but on the
>> other it would make package version not monotonically increasing.
>>
>> I could create upstream/0.5tizen.gitXXXXXX but that looks like
>> overkill.
>>
>> I went thru wiki pages and I'm still not sure how this should
>> be handled.
>>
>> (IOW, right now to compile module locally it should be enough
>>  to "git branch -d upstream")
>>
>>> Also, any idea what it will take to get dbus services to work on ivi
>>> images?
>>
>> In theory these should "just work" thanks to transparent
>> dbus1-kdbus proxy as provided by systemd-bus-proxyd.
>>
>> Practice is quite different with many services segfaulting,
>> including bus-proxyd itself.
>>
>> We will start looking into these issues, fixing one by one,
>> starting from next monday.
>>
>> Please also take into account what Casey wrote - currently
>> kdbus offers no security at all, and it will take some time
>> before this changes.
>>
>>
>> Thanks!
>> Karol
>>
>>> On Fri, Jan 24, 2014 at 12:18 PM, Clark, Joel <[email protected]>
>>> wrote:
>>>>
>>>>
>>>> On 01/24/2014  Karol Lewandowski wrote:
>>>>> On 01/24/2014 12:02 PM, Dominig ar Foll (Intel OTC) wrote:
>>>>>>
>>>>>> Le 22/01/14 20:38, Karol Lewandowski a écrit :
>>>>>> To be a viable solution, kdbus will need to land in kernel official
>>>>>> release in a workable model (inclusing smack support).
>>>>>
>>>>> Is it really the case?  In tizen we are carrying quite a few patches
>>>>> that weren't integrated into upstream projects. Our whole security
>>>>> model depends on this (upstream dbus-daemon doesn't >support smack if
>>>>> I'm not mistaken).
>>>>
>>>> It is certainly true for Tizen IVI for IA.  We usually have 0 out of
>>>> tree kernel patches. Maintaining out of tree kernel patches is too
>>>> resource intensive.
>>>>
>>>> Regards Joel Clark
>>>>
>>>> _______________________________________________
>>>> Dev mailing list [email protected]
>>>> https://lists.tizen.org/listinfo/dev
>>
>>
>> _______________________________________________
>> Dev mailing list
>> [email protected]
>> https://lists.tizen.org/listinfo/dev
> _______________________________________________
> Dev mailing list
> [email protected]
> https://lists.tizen.org/listinfo/dev
> 

_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

Reply via email to