Messages in this thread |  | | Date | Wed, 15 Apr 2015 13:20:37 -0400 | From | Steven Rostedt <> | Subject | Re: [GIT PULL] kdbus for 4.1-rc1 |
| |
On Wed, 15 Apr 2015 18:40:33 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Wed, Apr 15, 2015 at 11:41:53AM -0400, Steven Rostedt wrote: > > > > And obviously there is a lack of trust. And once kdbus is in, we must use > > it, or support our own distro where we just do not have the time. > > Just like cgroups, and ftrace :)
Exactly.
> > > Personally, I'm fine with getting something in that will help userspace > > tools work better. The issue I see, mostly from the side lines as I haven't > > totally submerged myself into the dbus protocol (I think I should spend > > some time to do just that), this is going too fast. Once it is in the kernel, > > whatever ABI we expose is locked in stone. There's no changing it. We need > > to make sure that this is well thought out. People seem to be of the impression > > that the current dbus design has flaws, but because everything relies on it > > we must still push it into the kernel because it mimics what is out there > > in user space. I disagree. > > "fast"? Are you kidding me? This stuff has been under active, public, > development for over two years. We have been posting public patches, > asking for review and comments for _months_ now. Given that there were > no more specific review comments on the patch set, and its success in > linux-next for almost the entire 4.0 development cycle, I asked it to be > merged. > > I don't know too many other kernel features/drivers that have taken this > long, or done this "slowly", do you?
What other features/drivers that you know introduce a major new IPC user space interface that will be a core component of the system?
> > > As others have said. We do not need to follow the dbus design. If we can supply > > a better transport layer than what the kernel supplies today, then tools will > > eventually merge to it away from dbus. Perhaps the kernel can supply just enough > > to have dbus improve its speed, but not with the entire complex solution that > > kdbus is presenting today. > > I originally thought this would work too. 8 months of work later, I was > proven wrong, that will not work. Or it imposes too much additional > work on userspace that really makes no sense at all. The in-kernel code > isn't a lot (again, 13k lines, smaller than almost all of the drivers > you are using today on an individual basis) It's also really fast, but > with benchmarks, David and Andy have found some minor bottlenecks that > can make things faster. > > Yes it seems complex, but read the documentation to get an idea of what > is happening here. I think you will get a better appreciation of what > is going on.
I read a bit of the documentation, but not enough. I really need to sit down and play with code. That's the way I learn and understand.
-- Steve
|  |