linux-kernel - Re: [PATCH -v25 00/49] Use memblock with x86

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: <4C44EF39.9000500@kernel.org>
Date:	Mon, 19 Jul 2010 17:35:05 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Johannes Weiner <hannes@...xchg.org>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH -v25 00/49] Use memblock with x86

On 07/19/2010 05:14 PM, Linus Torvalds wrote:
> On Mon, Jul 19, 2010 at 4:56 PM, Yinghai Lu <yinghai@...nel.org> wrote:
>> New memblock could be used to replace early_res in x86.
>>
>> Suggested by: David, Ben, and Thomas
> 
> So how is this related to Ben's git tree that was tested on sparc? Not
> clear from the changelog.

base on Ben's git tree that was tested on sparc.
fold one patch from me to patch 19. so will not break bisecting.

Maybe Ben can check patch from 3 to 27 to see if the folding is right or not.

> 
>> First two patches are needed for 2.6.35. need to be applied at first.
> 
> Please send those two as a separate series with a separate cover-sheet
> and explanation. If they are regressions or major fixes for existing
> code, they should not go into some 50-patch series for the future.
> That way they just get lost in the noise, and it's not at all as clear
> that they are important for current kernels.

those two are already in Andrew's -mm, but were not into tip/x86 yet.
and some of patches (patch 28-49) could have some merging conflicts if
those two are not applied at first.

> 
> In fact, in general, the fewer 50-series patches we see, the better.
> If a series of 50 patches could be split up into separate independent
> series ("independent" in the sense that they do different things -
> maybe one series depends on another series for infrastructure, but
> then actually concentrates on a different issue), that would be good.
> 
> Because, quite frankly, when I get email-bombed by tens of patches, I
> immediately lose about 99% of my eagerness to actually check the
> patches out. And I bet I'm not the only one. So it would likely be
> much more productive if these kinds of things can be sent out as
> multiple smaller series that can be looked at separately (and not sent
> out at the same time).

ok, 
1. let's wait Ingo or hpa to pick first two.
2. wait Ben to rebase patch 3-27, and send them out at first.
3. then I will resend from 28 to 49.

Thanks

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