Re: [GIT PULL] kdbus for 4.1-rc1

[Steven Rostedt]

On Wed, 15 Apr 2015 18:35:20 +0200
Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:


> > I suggest that we can do this at Linux Plumbers, and then follow up at
> > Kernel Summit, for those that can (or wont) attend plumbers.
> 
> I really doubt this will work for Plumbers, sorry.  And technical things
> don't work well, if at all, at Kernel Summit.
> 
> We have had meetings about this at the past two Plumbers conferences,
> where none of these things came up (i.e. dislike of the D-Bus model).

But were the people that are not liking it at those conference sessions?


> 
> I'll be glad to discuss this at both places, but let's try to work
> through the technical things through email, as really, that's the best
> place for it.
> 
> Al just proved this by pointing out some issues to be resolved (RW lock
> only used as a W lock, odd atomic values and locking without documenting
> the lifecycles, etc.)  And that's the way this is supposed to work,
> nothing new/different here that I can see.

But you are missing one of the complaints that I'm reading from
people. The proposed ABI is too complex. Do we really want to jump into
having to support another tty layer?

One thing that I think may be really worth doing is that everyone on
this thread that has not yet done so, write a simple dbus application
to try to understand its design. Break it down to the requirements that
are needed, and discuss that.

Is there a reason that this patch must go in this merge window? Having
something this controversial take place during the merge window
suggests its a bit premature to push in now. Especially since it
creates a new user space interface. I think we need to really think
hard and long before we add something that can not be modified at a
later date.

I personally think face to face may help, even if it's just hallway
tracks. But at a minimum, I think more kernel developers need to play
with dbus to understand this more. And then be able to give a better
feedback. I'm also thinking that the bare minimum for a transport layer
should go in. Find out the exact requirements (as Alan suggested) and
implement that, instead of just implementing the full layer that is
happening in userspace today.

-- Steve

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