Re: [GIT PULL] kdbus for 4.1-rc1

[Steven Rostedt]

On Wed, 15 Apr 2015 19:31:45 +0200
Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:

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

Exactly, but if you invite those people, and say "hey, here's your
chance to set us straight" maybe they'll come. I would.

But give them a few weeks notice, so that they can study what's out
there.


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

We are all making our own little exaggerated metaphors. ;-)

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

No, but people seems to be worried about the complexity. If everyone
understands that there's no other choice but to have it complex (like
RCU is), then everyone will be fine with it. But right now, people are
questioning why it needs to be complex. But we need more people to
spend time on it to make sure it does.


> > 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 still need to play with the code and see exactly what it does. What
goes into the kernel needs to be the raw interface only. Everything
else should be in a library that takes care of the details. Is that
what is here?


> 
> 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 this what is being proposed (again, I need to go back and read the
original change log. I did it once, but mostly forgot what was in it).

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

Well, there's been a few minor things that have been pointed out (the
locking), and having something as small as that take place during a
merge window, to me, would be cause to wait another merge window.

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

But there are still complaints about it. Perhaps people are just
noticing. We are all busy, and nobody (but perhaps Andrew Morton and
Jon Corbet) reads every LKML message. It's now getting more eyes.
That's a good thing.

I'd like more time to play with it so that I can understand why exactly
it needs to go in as you say it does.

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