Looks to me like the first series of patches should be OK to post now.
I propose that:
001-apply-to-page-range.patch
001a-reboot-use-struct.patch
002-sync-bitops.patch
003-remove-ring0-assumptions.patch
004-abstract-asm.patch
005-cpuid-cleanup.patch
unfix-fixmap.patch
fixmap-bootparam.patch
remove-read-hazard-from-cow.patch
pte-clear-not-present.patch
pgd-free-mm.patch
notes-segment.patch
are all good candidates for posting. I just went through all these and
cleaned them up a bit, mostly by adding Subject: lines and diffstats,
but I also merged unfix-fixmap-fix.patch with unfix-fixmap.patch and
renamed fixmap-bootparam to fixmap-bootparam.patch.
Oh, and these patches seem to work OK too. I'm running my laptop with
this part of the series applied, and it seems fine.
Yes? No? Maybe? Post more? Post less?
J
Jeremy Fitzhardinge wrote:> Looks to me like the first series of patches should be OK to post > now. I propose that: > > 001-apply-to-page-range.patch > 001a-reboot-use-struct.patch > 002-sync-bitops.patch > 003-remove-ring0-assumptions.patch > 004-abstract-asm.patch > 005-cpuid-cleanup.patch > unfix-fixmap.patch > fixmap-bootparam.patch > remove-read-hazard-from-cow.patch > pte-clear-not-present.patch > pgd-free-mm.patch > notes-segment.patch > > are all good candidates for posting. I just went through all these > and cleaned them up a bit, mostly by adding Subject: lines and > diffstats, but I also merged unfix-fixmap-fix.patch with > unfix-fixmap.patch and renamed fixmap-bootparam to > fixmap-bootparam.patch. > > Oh, and these patches seem to work OK too. I'm running my laptop with > this part of the series applied, and it seems fine. > > Yes? No? Maybe? Post more? Post less?Thanks for combining the patches (and fixing my unfix-fixmap-fix patch). Yes. Maybe more. I'd like to see Ian, Keir and Andrew's feedback on the applicability of the lazy MMU mode patches to Xen. I'd also like to get my ptep_establish optimization into the -mm tree asap. Not that either of these are a blocker. What we have now is good for everyone, I think. Zach
On Mon, 2006-07-31 at 01:06 -0700, Jeremy Fitzhardinge wrote:> Looks to me like the first series of patches should be OK to post now. > I propose that: > > 001-apply-to-page-range.patch > 001a-reboot-use-struct.patch > 002-sync-bitops.patch > 003-remove-ring0-assumptions.patch > 004-abstract-asm.patch > 005-cpuid-cleanup.patchYep, fairly clear. There was some naming queries about the DISABLE_INTERRUPTS vs _CLI etc, but I think they're OK.> unfix-fixmap.patchOK, I'm still not convinced on making __FIXMAP_TOP a variable rather than just defining it to something in the paravirt_ops structure. The latter is a 3 line patch, and much clearer in intent.> fixmap-bootparam.patchWhile this would justify the above patch, it is IMHO, the wrong approach for adding a paravirt module later: a module shouldn't fail to load because you forgot a boot cmdline param. I really think a #ifdef CONFIG_XXX_MODULE would be clearer.> remove-read-hazard-from-cow.patch > pte-clear-not-present.patch > pgd-free-mm.patchThese look like general goodness to me.> notes-segment.patchBe nice to see a user of this infrastructure, given it's fairly significant. Didn't someone mention PPC using something like this? Could we turn this into a "move infrastructure into arch-indep" patch?> Yes? No? Maybe? Post more? Post less?Post those, I'd say. I think it's your turn? Rusty. -- Help! Save Australia from the worst of the DMCA: http://linux.org.au/law