Jeremy Fitzhardinge wrote: > Zachary Amsden wrote: > >> Yeah, actually that does work, since you pass the km_type, we can use >> that. But I would rather not respin this for 2.6.21; getting this >> 100% right can be tricky, and we've already done a good deal of >> testing on this patch the way it is. >> > > It seems fairly low risk to me; its basically the same structure with > the same calls happening in the same order, but just slightly rearranged > in the source. Of course, if I'd seen this patch earlier I could have > given you earlier feedback... > I've been sending out this particular patch or a variant of it for a long time. It did get lost for a while during the paravirt-ops conversion, however. You're the first to give any feedback on it. >> Do you have any objection to me creating a patch for -mm tree that >> implements kmap_atomic_pte the way you have described above and >> attaching it to the Xen patch series, but leaving the current patch as >> is for now? >> > > Not particularly, but it seems odd to put something in knowing its going > to be immediately replaced. What's the urgency? > Better to keep what is known working for now, even if it is going to be replaced later... code is easy to change in development cycles, less easy to fix when nearing release. It really is easy to mess up one of the pte conversions by, say, shift the wrong value or calculate wrong or PAE dependent PTE offset. Plus it is harder to test, since you need > 896 M memory for your VM before the code even gets run. Not that I expect anything to go wrong with it, but I would prefer to err on the side of caution for now, that's all. Zach
