On Fri, May 1, 2015 at 9:48 PM, Andy Lutomirski wrote:
> Havoc, am I missing something here? If I'm right about this aspect of
> D-Bus, then I'm a bit surprised.
>
I'm not well-informed about Binder, though from reading about it, it
seems to be modeled on and comparable to COM.
>From what I can
On Tue, Apr 28, 2015 at 7:12 PM, John Stoffel wrote:
> Havoc> Yeah. I don't know how you answer that, because the answer is
> Havoc> probably "it would be good enough for some things and not for
> Havoc> other things." It depends on whether an app is sending enough
> Havoc> data to be too slow, an
On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o wrote:
> So the question is if one of the justifications for moving the daemon
> into kernel space is that it's performance is crap, then I think it is
> useful to determine whether a fully optimized userspace daemon would
> be good enough.
>
Yeah. I
On Tue, Apr 28, 2015 at 1:19 PM, David Lang wrote:
> If the examples that are being used to show the performance advantage of
> kdbus vs normal dbus are doing the wrong thing, then we need to get some
> other examples available to people who don't live and breath dbus that 'so
> things right' so t
btw if I can make a suggestion, it's quite confusing to talk about
"dbus" unqualified when we are talking about implementation issues,
since it muddles bus daemon vs. clients, and also since there are lots
of implementations of the client bindings:
http://www.freedesktop.org/wiki/Software/DBusBi
On Mon, Apr 27, 2015 at 6:14 PM, Linus Torvalds
wrote:
> The real problems seem to be in dbus memory management (suggestion:
> keep a small per-thread cache of those message allocations) and to a
> smaller degree in the crazy utf8 validation (why the f*ck does it do
> that anyway?), with some lock
On Mon, Apr 27, 2015 at 6:00 PM, Linus Torvalds
wrote:
> If somebody wants to speed up dbus, they should likely look at the
> user-space code, not the kernel side.
To be more precise, your profile seems to show a lot of the gdbus
(glib bindings) user space code. (And the blocking version of this
On Fri, Apr 24, 2015 at 9:50 AM, Lukasz Skalski wrote:
> - client: http://fpaste.org/215156/
>
Cool - it might also be interesting to try this without blocking round
trips, i.e. send requests as quickly as you can, and collect replies
asynchronously. That's how people ideally use dbus. It should
On Wed, Apr 22, 2015 at 5:48 PM, Linus Torvalds
wrote:
>
> Conditional byte order is worse than silly - it's terminally stupid.
>
Hey, usually I write a long rant myself, but I was trying to keep it
to one bullet point for once in my life. Way to ruin it, geez.
Havoc
--
To unsubscribe from this
On Wed, Apr 22, 2015 at 10:35 AM, Michele Curti wrote:
>
> Just out of curiosity, would you like to change something in dbus design,
> if you didn't have to worry about ABI breaks and the like?
>
Good question. I can't remember any big-picture things, I'm sure the
current maintainers and users ha
On Wed, Apr 22, 2015 at 7:40 AM, Austin S Hemmelgarn
wrote:
> Except, IIRC, that was one of the stated design goals in the original patch
> set. I'm pretty sure that i remember a rather verbose exposition that
> pretty much could be summarized as "Linux has no general purpose IPC in the
> kernel,
On Tue, Apr 21, 2015 at 9:51 PM, Bernd Petrovitsch
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 year
Hi,
On Tue, Apr 21, 2015 at 5:07 AM, Johannes Stezenbach wrote:
> My line of thinking had been to amend DBus with optional direct
> client/server communication for the performance critical
> cases, since I believe those cases are RPC calls and not other
> types of messaging (see also the "Perform
Hi,
On Fri, Apr 17, 2015 at 3:27 PM, James Bottomley
wrote:
>
> This is why I think kdbus is a bad idea: it solidifies as a linux kernel
> API something which runs counter to granular OS virtualization (and
> something which caused Windows to fall behind Linux in the container
> space). Splittin
On Fri, Apr 17, 2015 at 9:23 AM, Daniel Mack wrote:
>
> This can only happen with user-originated DBus signal messages. For
> unicast messages such as method calls, the sender will actually see
> -EXFULL, and no part of the message is transmitted, leaving neither side
> in a confused state.
Well
On Thu, Apr 16, 2015 at 9:13 AM, Tom Gundersen wrote:
> All types of messages (unicast and broadcast) are directly stored into
> a pool slice of the receiving connection, and this slice is not reused
> by the kernel until userspace is finished with it and frees it. Hence,
> a client which doesn't
On Wed, Apr 15, 2015 at 6:22 PM, One Thousand Gnomes
wrote:
> Actually most message passing code uses things like JMS and the various
> MQ libraries. Most IoT uses things other than dbus, small deep embedded
> never uses dbus.
fwiw, to me it's a mistake to think of dbus as "the same space" as
som
On Wed, Apr 15, 2015 at 4:22 PM, Andy Lutomirski wrote:
>
> This leads me to a potentially interesting question: where's the
> buffering? If there's a bus with lots of untrusted clients and one of
> them broadcasts data faster than all receivers can process it, where
> does it go?
>
> At least wi
On Wed, Apr 15, 2015 at 2:16 PM, Steven Rostedt wrote:
> But can't a dbus library handle this for the apps? Like implementing TCP on
> top of UDP. I really doubt the entire dbus protocol needs to be pushed into
> the kernel.
You could probably do something like assign sequence numbers,
temporaril
On Wed, Apr 15, 2015 at 1:20 PM, Steven Rostedt wrote:
> I read a bit of the documentation, but not enough. I really need to sit
> down and play with code. That's the way I learn and understand.
>
It might be useful for some of the current devs to post about the best
APIs to play with these days
On Wed, Apr 15, 2015 at 12:00 PM, Rik van Riel wrote:
> On 04/15/2015 07:06 AM, One Thousand Gnomes wrote:
>
>>> that anyone here does either. In the many years I've spent working on
>>> this, dbus has seemed to be odd, and strange, to the way that the kernel
>>> has normally worked, because it i
Hi,
I'm temporarily joining the list if anyone has questions about why
dbus was originally the way it is. If you would like answers about its
latest usage, systemd, or the kernel implementation, those are best
answered by others.
I "led" the original design but I was hardly the only person involv
22 matches
Mail list logo
