lkml.org 
[lkml]   [2015]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [GIT PULL] kdbus for 4.1-rc1
On Tue, Apr 21, 2015 at 9:51 PM, Bernd Petrovitsch
<bernd@petrovitsch.priv.at> wrote:
> Hi all!
>
> On Die, 2015-04-21 at 09:37 -0400, Havoc Pennington wrote:
> [...]
>> This has long been sort of the 'party line' and I've told many people
>> this on the dbus mailing list over the years (almost exactly what you
>> just said - that for performance-critical cases they should open a
>> direct socket or use something else or whatever). Usually this makes
>> app developers a little cranky because something that was going to be
>> easy in their mind just got harder.
>
> Perhaps these developers should rethink the design and protocols of
> their apps - or pay the price for a stupid design which relies on heavy
> IPC traffic (and usually - sooner or later - heavy network traffic).
> Or - at least - deliver a (technical!) proof why this isn't feasible.
>
> The case of "patching the kernel to lie about the kernel's command line"
> just because some ill-designed user-space daemon misused it" was bad
> enough and the above smells quite similarly.
>

I don't think it's ridiculous that app developers try the clean,
simple solution first (use one IPC for everything) and only optimize
once they discover they need to.

If dbus were faster, many of these designs might not be stupid and
might not be a mis-use. And the app might delete a lot of code, which
is a plus for anyone using that app. More code = more bugs after all.

I grant you that some apps have bad code, but I don't think it's my
job to punish them by making things slow on purpose. I only made
things slow because I didn't know a way to make them fast without
sacrificing a more important goal, but it was never ideal. The kdbus
developers have proposed a way out of the tradeoff.

Havoc


\
 
 \ /
  Last update: 2015-04-22 05:21    [W:0.065 / U:1.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site