Re: [GIT PULL] kdbus for 4.1-rc1

[Greg Kroah-Hartman]

On Wed, Apr 15, 2015 at 12:33:30AM +0200, Jiri Kosina wrote:
> On Tue, 14 Apr 2015, Greg Kroah-Hartman wrote:
> 
> > Yes, it's an unfortunate design, but one that we are all stuck with 
> > (think of it as having to implement code for horrid hardware that you 
> > have to get to work properly.)  
> 
> Greg, I personally consider this a rather defunct analogy. Broken hardware 
> comes from "outter space" we just have to live with somehow, and 
> eventually try to gradually improve by working with vendors (and you 
> yourself have of course made huge improvements in this very area).
> 
> Linux userspace is coming, well, from Linux developers. The sole fact that 
> someone wrote a daemon that runs on Linux seems like a very poor 
> justification for sucking the daemon into kernel "because we have to live 
> with it". 
> Userspace has to live with it somehow (and eventually fix itself if 
> necessary), yes. Why should kernel just contribute to this "unfortunate 
> design" if it really isn't, in any way, obliged or forced to do so?

I retract my "unfortunate design" statement, as Havoc pointed out
exactly why that design is the way it is, and it makes sense to me.

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 :)

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
real problem in this area, one that everyone has congregated on as the
best-known solution for that issue.  It's used everywhere, on servers,
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
somehow say that it's a "horible protocol" is terribly unfair, and
unkind, to all of the people who have worked to make it the best
possible solution for this problem space.

And honestly, I don't have a better proposal.  And I seriously doubt
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.

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.

And I'll defer back to the old AF_DBUS proposal, which was looked at
from a technical point of view of the network developers who said that
they didn't think that putting the D-Bus model into a network stack made
any sense from a technical point of view, and outligned their
objectsions.  And they were right, hence this different proposal many
years later based on their insight and suggestions.

If you have objections like that, great, please let me know.

thanks,

greg k-h
--
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/