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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 19 Feb 2009 16:08:51 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	Yang Hongyang <yanghy@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	Borislav Petkov <petkovbb@...glemail.com>
Subject: Re: [PATCHv2 00/11]Get rid of all the old macro DMA_nBIT_MASK and
	use DMA_BIT_MASK(n) instead


* Stefan Richter <stefanr@...6.in-berlin.de> wrote:

> Yang Hongyang wrote:
> > v1->v2:fix s/micro/macro typo and keep the old defines
> >             of DMA_nBIT_MASK
> > ----------------------
> > Replace all DMA_nBIT_MASK macro with the new DMA_BIT_MASK(n) macro
> > 
> > 01:Replace all DMA_64BIT_MASK macro with DMA_BIT_MASK(64)
> > 02:Replace all DMA_48BIT_MASK macro with DMA_BIT_MASK(48)
> > 03:Replace all DMA_40BIT_MASK macro with DMA_BIT_MASK(40)
> > 04:Replace all DMA_39BIT_MASK macro with DMA_BIT_MASK(39)
> > 05:Replace all DMA_35BIT_MASK macro with DMA_BIT_MASK(35)
> > 06:Replace all DMA_32BIT_MASK macro with DMA_BIT_MASK(32)
> > 07:Replace all DMA_31BIT_MASK macro with DMA_BIT_MASK(31)
> > 08:Replace all DMA_30BIT_MASK macro with DMA_BIT_MASK(30)
> > 09:Replace all DMA_28BIT_MASK macro with DMA_BIT_MASK(28)
> > 10:Replace all DMA_24BIT_MASK macro with DMA_BIT_MASK(24)
> > 11:Update the old macro DMA_nBIT_MASK related documentations
> > 
> 
> Shouldn't you organize the patch series per subsystem, not per old
> macro?  And then Cc the respective maintainers?
> 
> As it stands, the patches cannot be routed through the normal channels;
> yet there is no fundamental reason to handle these patches differently
> from normal patches.

Traditionally such trivially correct convert-it-all patches 
lived in -mm and were merged upstream in one go, near the end of 
the merge window.

Sprinkling it into dozens of subsystem channels (some of which 
are very unreliable) is neither good nor an economic use of our 
resources.

Patches that can potentially cause trouble should go via the 
usual channels.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ