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 :) > 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? > 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. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/