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:	Sat, 5 Jun 2010 11:35:42 +0300
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Minchan Kim <minchan.kim@...il.com>,
	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 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?

                            Pekka
--
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/