lkml.org 
[lkml]   [2015]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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


\
 
 \ /
  Last update: 2015-04-15 23:01    [W:0.327 / U:0.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site