On Wed, Apr 15, 2015 at 9:44 AM, Havoc Pennington <h...@pobox.com> wrote: > On Wed, Apr 15, 2015 at 12:00 PM, Rik van Riel <r...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
