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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 Jun 2010 08:32:50 +0900
From:	Minchan Kim <minchan.kim@...il.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Nitin Gupta <ngupta@...are.org>, Greg KH <greg@...ah.com>,
	Ed Tomlinson <edt@....ca>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Cyp <cyp561@...il.com>, driverdev <devel@...verdev.osuosl.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] Support generic I/O requests

Hi, Pekka.

On Sat, Jun 5, 2010 at 5:35 PM, Pekka Enberg <penberg@...helsinki.fi> wrote:
> Hi Andrew,
>
> On Fri, Jun 4, 2010 at 10:19 PM, Andrew Morton
> <akpm@...ux-foundation.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/