On Sat, Jun 21, 2014 at 12:29:01PM -0700, James Bottomley wrote: > On Thu, 2014-06-19 at 14:58 -0700, Daniel Phillips wrote: > > On Thursday, June 19, 2014 2:26:48 AM PDT, Lukáš Czerner wrote: > > > Let me remind you some more important problems Dave brought up, > > > including page forking: > > > > > > " > > > The hacks around VFS and MM functionality need to have demonstrated > > > methods for being removed. > > > > We already removed 450 lines of core kernel workarounds from Tux3 with an > > approach that was literally cut and pasted from one of Dave's emails. Then > > Dave changed his mind. Now the Tux3 team has been assigned a research > > project to improve core kernel writeback instead of simply adapting the > > approach that is already proven to work well enough. That is a rather > > blatant example of "perfect is the enemy of good enough". Please read the > > thread. > > That's a bit disingenuous: the concern has always been how page forking > interacted with writeback. It's not new, it was one of the major things > brought up at LSF 14 months ago, so you weren't just assigned this. BTW, it's worth noting that reviewers are *allowed* to change their mind at any time during a discussion or during review cycles. Indeed, this occurs quite commonly. It's no different to multiple reviewers disagreeing on what the best way to make the improvement is - sometimes it takes an implementation to solidify opinion on the best approach to solving a problem. i.e. it took an implementation of the writeback hook tailored specifically to tux3's requirements to understand the best way to solve the infrastructure problem for *everyone*. This is how review is supposed to work - take an idea, and refine it into something better that works for everyone. We'd have been stuck way up the creek without a paddle a long time ago if reviewers weren't allowed to change their minds.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
