Re: [GIT PULL] kdbus for 4.1-rc1

[One Thousand Gnomes]

> To quote the email that he wrote:
> 	The reason is that dbus views the world in a stateful way
> 	assuming that connections, and name ownership, can be tracked
> 	reliably.  This is different from say http, and it's one reason
> 	that people used to Internet-oriented protocols find dbus
> 	strange.
> 
> I'm one of those "people used to internet-oriented protocols", and I bet
> that almost all of us kernel developers also fall into that category, as
> the kernel for the most part, is one big tool to help implement those
> Internet-oriented protocols :)

I worked on protocols with state. I suffered X.25, X.29, coloured book,
ISDN. It's a completely *crap* model. It has unfixable reliability
problems. It has unfixable flow control problems. The only thing it buys
you is the ability to have more traffic in flight between end points than
you have transient memory for at the endpoints.

You don't need a grand unified state to track service locations and access
(ie names), which is fortunate or we'd be rebooting the internet and
all attached computers all the time.

> The very history of D-Bus, where it came from, who is now using it, what
> happened to all of the other proposed solutions in this area, is worth
> examining if you are interested in it.  This type of protocol solves a

History is why you got where you did. The history of Windows 98 explains
how they got there. It doesn't mean that continuing the same mistake is a
good idea.

> embedded systems, desktops, you name it.  All languages have bindings
> for it, and it's the underpinning of a modern Linux stack.  For us to

Everything used to have just a choice of COBOL or FORTRAN bindings. That
was not a good reason to continue to program the world in either of them.

> 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

> Now if there are technical problems or insecurities in the proposed code
> submission, wonderful, please let me know and I'll be glad to work to
> address them.  But let's just drop the whole "oooh, look, D-Bus is
> horrible looking, we can't support that!", is not a valid justification.

We can however leave it in userspace until we understand the right small
clean way to support it and other needs. At the moment for example
cluster people can't really use this stuff because its not network aware,
and HPC people can't use it because it's got dbus hardwired into it so
can't speak MPI-3 and the like even though MPI 3 has similar concepts
around DPM, as well as having proper models for parallelism and
collective operations that are lacking in dbus.

If the userspace folks choose to continue to implement dbust over it but
the kernel layer is clean and generic then all is good, because someone
can replace dbust with something better. If its got dbust hard wired into
it then its a complete mess.

Alan
--
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/