On Tue, Oct 23, 2018 at 5:54 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Tue, Oct 23, 2018 at 05:44:32PM +0530, Souptick Joarder wrote: > > On Sat, Oct 6, 2018 at 4:19 PM Miguel Ojeda > > <miguel.ojeda.sandonis@xxxxxxxxx> wrote: > > > > > > On Sat, Oct 6, 2018 at 7:11 AM Souptick Joarder <jrdr.linux@xxxxxxxxx> wrote: > > > > > > > > On Fri, Oct 5, 2018 at 11:39 PM Miguel Ojeda > > > > <miguel.ojeda.sandonis@xxxxxxxxx> wrote: > > > > > They are not supposed to be "steps". You did it with 70+ commits (!!) > > > > > over the course of several months. Why a tree wasn't created, stuff > > > > > developed there, and when done, submitted it for review? > > > > > > > > Because we already have a plan for entire vm_fault_t migration and > > > > the * instruction * was to send one patch per driver. > > > > > > The instruction? > > > > Sorry for the delayed response. > > Instruction from Matthew Wilcox who is supervising the entire vm_fault_t > > migration work :-) > > Hang on. That was for the initial vm_fault_t conversion in which each > step was clearly an improvement. What you're looking at now is far > from that. Ok. But my understanding was, the approach of vm_insert_range comes into discussion as part of converting vm_insert_page into vmf_insert_page which is still part of original vm_fault_t conversion discussion. No ? _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
