Re: [GIT PULL] kdbus for 4.1-rc1

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Wed, Apr 15, 2015 at 01:06:49PM -0400, Steven Rostedt wrote:
> On Wed, 15 Apr 2015 18:35:20 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> 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?

People who don't like a topic, usually go to a session about it, why
would they? :)

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

Don't make idle comments, the tty layer is far more complex and larger
than the kdbus code, with much nastier issues and problems.  And we
handle that just fine :)

As far as the "support" issue, we have 4 people who are all experienced,
senior kernel developers who are signed up to maintain this.  There's
more experience here for this one MAINTAINERS entry per line of code
than I have seen in quite some time.

Are people somehow worried that all 4 of us are going to run away?  Do
people not trust the 4 of us to stick around and maintain this and deal
with any issues found for the next few decades?  If so, please let us
know, as it seems like people feel we are dumping this code on them to
maintain, which is anything but true.

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

I've done that, it's hard, use the gdbus interface instead, it makes
your life much easier.

I'll again refer to ALSA here, no one writes a "raw" ALSA program, they
all use the library to interact with the kernel.  Do that here, there
are wonderful dbus libraries out there, for all languages.  Use them
instead.

> Is there a reason that this patch must go in this merge window?

What makes this merge window any different from any other?  Again, I
explained why I asked it to be merged at this point in time.  If people
have technical issues with it, I'll be more than glad to work them out
and merge it later, there's no "hard and fast deadline" anyone is asking
for here.

> Having something this controversial take place during the merge window
> suggests its a bit premature to push in now.

"take place"?  Have you been ignoring these patches posted numerous
times for many months?  This is the point in time to ask for code to be
merged, just like any other code, nothing is special here.

thanks,

greg k-h