lkml.org 
[lkml]   [2015]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] kdbus for 4.1-rc1
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



\
 
 \ /
  Last update: 2015-04-15 19:21    [W:0.428 / U:7.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site