> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of HyungJun Choi
> Sent: Monday, November 04, 2013 8:44 AM
> To: 'Thiago Macieira'; [email protected]
> Subject: Re: [Dev] [RFC] kdbus transport for DBus
> 
> >> Why do I feel like I'm missing something?
> >>
> >> We want kdbus to improve performance.
> >
> >Yes.
>  I agree with you.
> 
> >> Many/most/some dbus applications will require porting.
> >
> >Yes.
>  Depend on libraries which are using application.
>  Applications are using,
>  - libdbus, libdbus-bindings (ie. Dbus-glib, edbus, Etc.), gdbus  ->
> No.
>  - applications are using different libraries above -> Yes.
> 
> 
> >> That is too much work, so we need a compatibility daemon that is
> going
> >> to suck away any performance gain, and in fact probably make
> >> performance worse.
> >
> >Quite possibly.
>  No.
> 
> >> We're counting on the widespread adoption of kdbus in the future,
> >> which will get the performance back as everyone ports everything
> from
> dbus to kdbus.
> >
> >Yes.
> >
> >> I can see kdbus as a long term plan.
> >>
> >> I can't image why it makes any sense at all for Tizen3.
> >
> >Nor I. Unless there are specific gains to be had for specific daemons
> that
> we plan on porting, I don't see the point of going ahead >of upstream.
> >
>    We have a kdbus solution already and it's working now.
>    Our solution is not using a bus bridge or something.
> 
> >> I see lots of work and a system that does not perform as well as it
> >> does today with "real" dbus.
> >>
> >> Someone please tell me what I'm missing.
> >
> >You're missing that kdbus is still not ready for prime time.
> 
> "The work on kdbus is progressing well and Kroah-Hartman expressed
>  optimism that it would be merged before the end of the year"
>  [http://lwn.net/Articles/551969/]

What's more according to Greg KH the work on kernel part is considered done.
We provided upstream with fixes to some bugs that we had found during our
development, but as far as I know the whole effort is now put into client
side API which is not used in our solution. In our implementation we use
kernel module directly through ioctl calls.

We have triggered some additional work related to performance improvements
on ARM platform but that should not affect compatibility of our solution.

 
--
Jacek Janczyk
Samsung R&D Institute Poland
Samsung Electronics

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

Reply via email to