Re: [PATCH 1/4] Support generic I/O requests

[Minchan Kim]

Hi, Pekka.

On Sat, Jun 5, 2010 at 5:35 PM, Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote:
> Hi Andrew,
>
> On Fri, Jun 4, 2010 at 10:19 PM, Andrew Morton
> <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>>> I thought zram is related to memory management a little bit.
>>>
>>> What's the criteria?
>>
>> Yes, and this is something which bothers me a bit about the -staging
>> process. ÂCode gets in there largely under the radar of the people who
>> work in that area. ÂIt gets "matured" for a while and the developer
>> thinks it's all ready to go into "mainline" and .... Âthen what?
>> Someone needs to yank the code out of -staging and tell the interested
>> parties "hey, look at this". ÂAnd at this stage, they might say "hell
>> no", or request large changes and the developer who thought everything
>> was all ready to go would be justifiably upset.
>>
>> Obviously, this hasn't happened (much) with zram (partly because I
>> happened to notice it), but the potential is there.
>>
>> I'm not sure what a good solution is, really. ÂObviously it would be
>> better if such code went straight into the subsystem maintainer's tree
>> on day one and got worked on there. ÂBut if that process was working
>> efficiently, we wouldn't have ever needed ./staging/.
>
> I thought the idea here is that when zram is "good enough", Nitin or
> Greg would post squashed patches of it for review and if maintainers
> are ready to take it, we'd merge the full history from -staging.
>
> Not sure what Nitin's or Greg's plans are but I think it might be
> realistic to try to get zram properly merged for 2.6.36.
>
>> So I suppose we (ie: Greg ;)) should identify the destination
>> maintainer at the outset and make sure that the maintainer(s) and the
>> subsystem mailing list are kept in the loop on all developments, and
>> that they're aware that this code is headed their way. ÂPerhaps that's
>> already happening and I missed it.
>
> Ramzswap and zram have been discussed on LKML. I guess Nitin should
> have CC'd linux-mm as well for you to see it? There hasn't been huge
> interest in reviewing the code which is why I suggested -staging in
> the first place. It ought to be a place where we can do in-tree
> development while we wait for the busy maintainers to have the chance
> to look at the code, no?

Fair enough.

AFAIR, mm forks haven't been interest in reviewing the code except
allocator at that time. but at least, Greg or someone should have Cced
one maintainer or mailing list related to patches to notice them.
"It's growing in here(ie, staging) and be ready to go to the
mainline". :)

-- 
Kind regards,
Minchan Kim
--
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/