On Wed, 15 Apr 2015, Greg Kroah-Hartman wrote: > > I originally didn't want to comment on this, but now that you are > > making this argument for 3rd or 4th time, I can't really resist. What > > exactly are you trying to "prove" by the 13k-lines argument? > > > > mm/vmscan.c is less that 4k lines. Does that sole fact mean that the whole > > memory reclaim is trivial to review? > > I'm trying to say that it's not a ton of code. lines of code are of > course not a valid way to judge complexity, and I'm not trying to say > that. I am trying to point out that it isn't "huge" by comparing it to > other chunks of code that we all know and love. > > We merge subsystems with new userspace apis that are large than this all > the time. I'm trying to say this isn't something "unusual" at all.
I agree with you on that point. Merging 13k lines isn't a big deal, we do that all the time. But I don't think anyone in this (or previous) thread brought up the number of lines of kdbus as an unltimate argument for questioning or even NACKing it. So I completely fail to see why this is so relevant that you keep repeating it. Thanks, -- Jiri Kosina SUSE Labs -- 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/
