Re: [GIT PULL] kdbus for 4.1-rc1

[Havoc Pennington]

On Tue, Apr 21, 2015 at 9:51 PM, Bernd Petrovitsch
<bernd@xxxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/