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:	Fri, 4 Jun 2010 12:19:57 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Minchan Kim <minchan.kim@...il.com>
Cc:	Nitin Gupta <ngupta@...are.org>, Greg KH <greg@...ah.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	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

On Wed, 2 Jun 2010 15:20:13 +0900
Minchan Kim <minchan.kim@...il.com> wrote:

> P.S)
> Why don't you send this series to -mm?
> I don't know any patches have to go linux-next and any patches have to
> go --mmotm.

The code lives in drivers/staging/ at present.  That's Greg's tree.

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

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.

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