Re: [PATCH] staging: zsmalloc: add user-definable alloc/free funcs

[Greg Kroah-Hartman]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/