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]
Message-ID: <01bf01cbb6f2$cdba4a70$692edf50$@mprc.pku.edu.cn>
Date:	Tue, 18 Jan 2011 17:33:44 +0800
From:	"Guan Xuetao" <guanxuetao@...c.pku.edu.cn>
To:	"'Paul Mundt'" <lethal@...ux-sh.org>
Cc:	<sfr@...b.auug.org.au>, "'Arnd Bergmann'" <arnd@...db.de>,
	<gregkh@...e.de>, <jbarnes@...tuousgeek.org>,
	<dmitry.torokhov@...il.com>, <dtor@...l.ru>,
	<rubini@...l.unipv.it>, <linux-arch@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-fbdev@...r.kernel.org>,
	<linux-next@...r.kernel.org>
Subject: RE: Request for unicore32 architecture codes to merge into linux-next



> -----Original Message-----
> From: linux-next-owner@...r.kernel.org [mailto:linux-next-owner@...r.kernel.org] On Behalf Of Paul Mundt
> Sent: Tuesday, January 18, 2011 5:11 PM
> To: Guan Xuetao
> Cc: sfr@...b.auug.org.au; 'Arnd Bergmann'; gregkh@...e.de; jbarnes@...tuousgeek.org; dmitry.torokhov@...il.com; dtor@...l.ru;
> rubini@...l.unipv.it; linux-arch@...r.kernel.org; linux-kernel@...r.kernel.org; linux-fbdev@...r.kernel.org; linux-
> next@...r.kernel.org
> Subject: Re: Request for unicore32 architecture codes to merge into linux-next
> 
> On Tue, Jan 18, 2011 at 05:07:41PM +0800, Guan Xuetao wrote:
> > IMO, the whole architecture specific codes need to be merged first, and only some
> > necessary drivers are included under staging. Then, I could split the staging drivers
> > into corresponding mail-list, and then, additional drivers.
> > Otherwise, there are no architecture basic for drivers review.
> >
> That's of course fine so long as the driver changes are reasonably
> self-contained. The situation we want to avoid is that you end up with
> drivers that depend on some private infrastructure of API where not
> enough context is provided when the two are decoupled.
> 
> In any event, the architecture bits are the most self-contained and have
> had the most review of anything in this series of patches, so it probably
> makes sense to work on getting those bits integrated and then dealing
> with the rest incrementally.
Then, I should:
1. merge reviewed arch dir and reviewed drivers (for now, i8042)
2. submit staging drivers to review
Am I right?

Thanks.
Guan Xuetao

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ