> From: Greg KH [mailto:gregkh@xxxxxxxxxxxxxxxxxxx] > So, how about this, please draw up a specific plan for how you are going > to get this code out of drivers/staging/ I want to see the steps > involved, who is going to be doing the work, and who you are going to > have to get to agree with your changes to make it happen. > : > Yeah, a plan, I know it goes against normal kernel development > procedures, but hey, we're in our early 20's now, it's about time we > started getting responsible. Hi Greg -- I'm a big fan of planning, though a wise boss once told me: "Plans fail... planning succeeds". So here's the plan I've been basically trying to pursue since about ten months ago, ignoring the diversion due to "zcache1 vs zcache2" from last summer. There is no new functionality on this plan other than as necessary from feedback obtained at or prior to LSF/MM in April 2012. Hope this meets your needs, and feedback welcome! Dan ======= ** ZCACHE PLAN FOR PROMOTION FROM STAGING ** PLAN STEPS 1. merge zcache and ramster to eliminate horrible code duplication 2. converge on a predictable, writeback-capable allocator 3. use debugfs instead of sysfs (per akpm feedback in 2011) 4. zcache side of cleancache/mm WasActive patch 5. zcache side of frontswap exclusive gets 6. zcache must be able to writeback to physical swap disk (per Andrea Arcangeli feedback in 2011) 7. implement adequate policy for writeback 8. frontswap/cleancache work to allow zcache to be loaded as a module 9. get core mm developer to review 10. incorporate feedback from review 11. get review/acks from 1-2 additional mm developers 12. incorporate any feedback from additional mm reviews 13. propose location/file-naming in mm tree 14. repeat 9-13 as necessary until akpm is happy and merges STATUS/OWNERSHIP 1. DONE as part of "new" zcache; now in staging/zcache 2. DONE as part of "new" zcache (cf zbud.[ch]); now in staging/zcache (this was the core of the zcache1 vs zcache2 flail) 3. DONE as part of "new" zcache; now in staging/zcache 4. DONE as part of "new" zcache; per cleancache performance feedback see https://lkml.org/lkml/2011/8/17/351, now in staging/zcache; dependent on proposed mm patch, see https://lkml.org/lkml/2012/1/25/300 5. DONE as part of "new" zcache; performance tuning only, now in staging/zcache; dependent on frontswap patch merged in 3.7 (33c2a174) 6. PROTOTYPED as part of "new" zcache; protoype is now in staging/zcache but has bad memory leak; reimplemented to use sjennings clever tricks and proposed mm patches with new version posted https://lkml.org/lkml/2013/2/6/437; rejected by GregKH as it smells like new functionality (******** YOU ARE HERE *********) 7. PROTOTYPED as part of "new" zcache; now in staging/zcache; needs more review (plan to discuss at LSF/MM 2013) 8. IN PROGRESS; owned by Konrad Wilk; v2 recently posted http://lkml.org/lkml/2013/2/1/542 9. IN PROGRESS; owned by Konrad Wilk; Mel Gorman provided great feedback in August 2012 (unfortunately of "old" zcache) 10. Konrad posted series of fixes (that now need rebasing) https://lkml.org/lkml/2013/2/1/566 11. NOT DONE; owned by Konrad Wilk 12. TBD (depends on quantity of feedback) 13. PROPOSED; one suggestion proposed by Dan; needs more ideas/feedback 14. TBD (depends on feedback) WHO NEEDS TO AGREE Not sure I can answer that. Seth seems to now be pursuing a separate but semi-parallel track. Akpm clearly has to approve for any mm merge to happen. Minchan has interest but may be happy if/when zram is merged into mm. Konrad may be maintainer if akpm decides compression is maintainable separately from the rest of mm. (More LSF/MM 2013 discussion.) _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
