On Mon, Mar 26, 2012 at 11:50:19AM -0400, Konrad Rzeszutek Wilk wrote: > On Mon, Mar 19, 2012 at 04:34:09PM -0700, Greg Kroah-Hartman wrote: > > On Mon, Mar 19, 2012 at 01:54:56PM -0500, Seth Jennings wrote: > > > > I'm sorry, I know this isn't fair for your specific patch, but we have > > > > to stop this sometime, and as this patch adds code isn't even used by > > > > anyone, its a good of a time as any. > > > > > > So, this the my first "promotion from staging" rodeo. I would love to > > > see this code mainlined ASAP. How would I/we go about doing that? > > > > What subsystem should this code live in? The -mm code, I'm guessing, > > right? If so, submit it to the linux-mm mailing list for inclusion, you > > can point them at what is in drivers/staging right now, or probably it's > > easier if you just make a new patch that adds the code that is in > > drivers/staging/ to the correct location in the kernel. That way it's > > easier to review and change. When it finally gets accepted, we can then > > delete the drivers/staging code. > > > Hey Greg, > > Little background - for zcache to kick-butts (both Dan and Seth posted some > pretty awesome benchmark numbers) it depends on the frontswap - which is in > the #linux-next. Dan made an attempt to post it for a GIT PULL and an interesting > conversation ensued where folks decided it needs more additions before they were > comfortable with it. zcache isn't using those additions, but I don't see why > it couldn't use them. > > The things that bouncing around in my head are: > - get a punch-out list (ie todo) of what MM needs for the zcache to get out. > I think posting it as a new driver would be right way to do it (And then > based on feedback work out the issues in drivers/staging). But what > about authorship - there are mulitple authors ? What does authorship matter here? To move files out of staging, just send a patch that does that, all authorship history is preserved. And as a new driver, that's up to the mm developers, not me. > - zcache is a bit different that the normal drivers type - and it is unclear > yet what will be required to get it out - and both Seth and Nitin have this > hungry look in their eyes of wanting to make it super-duper. So doing > the work to do it - is not going to be a problem at all - just some form > of clear goals of what we need "now" vs "would love to have". Again, work with the -mm developers. > - folks are using it, which means continued -stable kernel back-porting. What do you mean by this? > So with that in mind I was wondering whether you would be up for: > - me sending to you before a merge window some updates to the zcache > as a git pull - that way you won't have to deal with a bunch of > small patches and when there is something you don't like we can fix > it up to your liking. The goal would be for us - Dan, Nitin, Seth and me > working on promoting the driver out of staging and you won't have to > be bugged every time we have a new change that might be perceived > as feature, but is in fact a step towards mainstreaming it. I figured > that is what you are most annoyed at - handling those uncoordinated > requests and not seeing a clear target. Lots of small patches are fine, as long as they are obviously working toward getting the code out of staging. This specific patch was just adding a new feature, one that no one could even use, so that was not something that would help it get out of the staging tree. So no, I don't need patches batched up, and a git pull, I just need to see that every patch I am sent is working toward getting it out of here. > - alongside of that, I work on making those frontswap changes folks > have asked for. Since those changes can affect zcache, that means > adding them in zcache alongside. Ok. > Hopefully, by the time those two items are done, both pieces can go in > the kernel at the same time-ish. That would be good to see have happen. thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
