Re: [GIT PULL] kdbus for 4.1-rc1

[James Bottomley]

On Wed, 2015-04-15 at 10:37 +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 15, 2015 at 12:05:01AM +0200, Jiri Kosina wrote:
> > On Tue, 14 Apr 2015, Steven Rostedt wrote:
> > 
> > > I believe that Linux Plumbers is still accepting MicroConferences. I 
> > > wonder if this would be a good one to have. Try to get everyone face to 
> > > face and talk about how exactly kdbus should be implemented in the 
> > > kernel.
> > 
> > I personally would even put more emphasis on a session that would first 
> > focus on "why", before we look at "how".
> > 
> > I have already asked about this during the earlier RFC submissions, but 
> > the only "take-home message" I took from that discussion was "because it's 
> > faster than what we currently have". I don't find that a sufficient 
> > justification by itself for something so complex (with potential 
> > implications all over the place for the whole Linux ecosystem), especially 
> > given the fact we already have sealed memfds zerocopy etc (and I am not 
> > even talking about the "infinite set-in-stone userspace API" implications 
> > this has).
> 
> I wrote many many lines of "why" in the patch submissions, and in the
> first email in this thread.  Are any of those specific solutions and
> "why" reasons not correct in your opinion?  If so, great, please let me
> know.
> 
> But to say that no one is focusing on "why" is a slight to those of us
> who have been providing just that.

Please stop. A debate that degenerates into a disagreement about whether
specific questions have or have not been answered is no debate at all:
it's an ideological show case.  If both sides are going to do the same
at plumbers (or elsewhere) it will be a waste of time (well, except as a
spectator sport).

To make this work, you need (as the plumbers MC templates tell you) a
list of key attendees from all sides of the debate who'll commit to
coming (mostly what I've heard so far is people committing not to
coming) and a list of guiding topics which people will commit to
discussing honestly.

For me the biggest issue is the container problem: it's really hard to
containerise kdbus because of the stateful nature of the protocol and
the fact that it has a well known system bus.  Separation into domains
works for OS containers, but application containers need more fluidity.
It's not unlike the same problem on windows: Windows application
containers are very difficult to do because the global registry means
that OLE handlers all have to run inside your container as well
(effectively making it an OS container).  I'm sure, since we already
have a lot of containers people going to plumbers, that we can get them
to turn up for the discussion.

James


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