Use memblock with x86
in [Kernel]
|
Prev: One question about the positions of flush_dcache_page and bounce_copy_vec methods in copy_to_high_bio_irq
Next: linux-next: Tree for July 7
From: Ingo Molnar on 7 Jul 2010 02:50 * Yinghai Lu <yinghai(a)kernel.org> wrote: > New memblock could be used to replace early_res in x86. > > Suggested by: David, Ben, and Thomas > 113 files changed, 2110 insertions(+), 2217 deletions(-) > create mode 100644 include/linux/memblock.h > delete mode 100644 kernel/early_res.c > delete mode 100644 lib/lmb.c > create mode 100644 mm/memblock.c Ok, this finally looks like a basis we could start productizing. If anyone has any fundamental, structural, design level [or naming] objection/feedback, which should be addressed before we start cutting a tree for this and start fixing bugs and move this towards an append-only workflow, please speak up. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 19 Jul 2010 20:20 On Mon, Jul 19, 2010 at 4:56 PM, Yinghai Lu <yinghai(a)kernel.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. > 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. 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? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 19 Jul 2010 20:40 On 07/19/2010 05:14 PM, Linus Torvalds wrote: > On Mon, Jul 19, 2010 at 4:56 PM, Yinghai Lu <yinghai(a)kernel.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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 20 Jul 2010 14:40
On 07/19/2010 05:35 PM, Yinghai Lu wrote: > > 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. > What part of "please send those two as a separate series with a separate cover-sheet and explanation" didn't you get? Quite frankly, I have been extremely frustrated with you over the last year over how you seem to think that the rules simply don't apply to you. It's time for you to realize that they do. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |