On Wed, Apr 15, 2015 at 11:09:48AM +0200, Greg Kroah-Hartman wrote: > > > But the problem really is that I don't think you've received even a single > > Reviewed-by: from someone who hasn't been directly involved in developing > > the code, right? > > I've asked for it, but finding people to review code is hard, as you
Perhaps try harder. You know more kernel developers than I do. You don't have anyone you can say "hey, I need this code reviewed, can you spend some time to review it for me"? I have a few developers that are willing to do that for me, and I wont push some code (if it is complex) until they give their review-by for it. I did that with the latest TRACE_DEFINE_ENUM() code, as well as my ftrace trampoline code and the multi buffer code. None of that went in until I had their reviewed-by tags. > know. It's only 13k lines long, smaller than a serial port driver (my > unit of code review), so it's not all that big. Length of code does not determine the complexity of it. > > It's smaller than the USB3 host controller driver as well, and very few > people ever reviewed that beast :) > > > For something that's potentially such a core mechanism as a completely > > new, massively-adopted IPC, this does send a warning singal. > > If you know of a way to force others to review code, please let me know. Keep asking, that's the best way. That's what I do. Also, I really like Alan's approach to this. Let me requote it here: - stop writing a dbus only file system - figure out what a messaging "vfs" looks like - figure out what an clean low level kernel model looks like - figure out what has to be where to put the policy in userspace -- Steve -- 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/
