Messages in this thread |  | | From | Andy Lutomirski <> | Date | Wed, 15 Apr 2015 13:22:12 -0700 | Subject | Re: [GIT PULL] kdbus for 4.1-rc1 |
| |
On Wed, Apr 15, 2015 at 9:44 AM, Havoc Pennington <hp@pobox.com> wrote: > On Wed, Apr 15, 2015 at 12:00 PM, Rik van Riel <riel@redhat.com> 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 is. And that's not a bad thing, it's >>>> just different, and for us to support real needs and requirements of our >>>> users, is the requirement of the Linux kernel. >>> >>> There are I think a set of intertwined problems here >>> >>> - An efficient delivery system for multicast messages delivered locally >>> (be that MPI, dbus whatever - it's not "dbus or nothing") >>> >>> - A kernel side dynamic namespace to describe what goes where >>> >>> - A kernel side security model to describe who may receive what, and >>> which additional information/tags/cred info >>> >>> - Something that provides state to stuff that needs it (and probably >>> belongs in userspace - dbus name service etc) >>> >>> - Something that maps dbus and other models onto the kernel security >>> model (and we have tools like EBPF which are very powerful) >>> >>> - Something that maps the kernel layer onto models like MPI-3 > > When trying to split apart problems, for dbus it's important to keep > ordering guarantees. > > That is, with dbus if I send a broadcast message, then send a unicast > request to another client, then drop the connection causing the bus to > broadcast that I've dropped; then the other client will see those > things in that order - the broadcast, then the request, and then that > I've dropped the connection.
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 with a userspace solution, it's clear what the OOM killer should kill when this happens. Unless it's PID 1. Sigh.
--Andy
|  |