Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions

On Tue, Feb 13, 2007 at 05:06:42PM -0800, Zachary Amsden wrote: > >I moved drm_follow_page into the core, to avoid having to wrap the > >various pte ops. Unlining kernel_fpu_end and using that in the RAID6 > >code would remove the need to export clts/read_cr0/write_cr0 too. Please don't push the

Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions

On Tue, 2007-02-13 at 17:06 -0800, Zachary Amsden wrote: > Jeremy Fitzhardinge wrote: > > Wrap the paravirt_ops members we want to export in wrapper functions. > > Since we binary-patch the critical ones, this doesn't make a speed > > impact. > > This turned out really hideous looking to me. Can'

Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions

Zachary Amsden wrote: > No, it needs to be part of the general patch list first, which is > still hand listed rather than just any op being patchable. Then it > can be up to the backend. Ah, right, yes. We need to add all (most? some?) of the pte operations to that list too. J - To unsubsc

Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions

Jeremy Fitzhardinge wrote: Zachary Amsden wrote: Ok. As long as we plan on patching CR2 and CR0 / clts accessors for FPU save during context switch and page fault paths in the future. That's up to each backend, right? Or do these need to be patched for a correctness reason? No,

Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions

Zachary Amsden wrote: > Ok. As long as we plan on patching CR2 and CR0 / clts accessors for > FPU save during context switch and page fault paths in the future. That's up to each backend, right? Or do these need to be patched for a correctness reason? J - To unsubscribe from this list: sen

Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions

Jeremy Fitzhardinge wrote: Zachary Amsden wrote: This turned out really hideous looking to me. Can't we split the struct into GPL'd and non-GPL'd functions instead? We still have the same granularity, and none of this function call to an indirect function call nonsense. It's not pre

Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions

Zachary Amsden wrote: > This turned out really hideous looking to me. Can't we split the > struct into GPL'd and non-GPL'd functions instead? We still have the > same granularity, and none of this function call to an indirect > function call nonsense. It's not pretty, but I think having paravir

Re: [patch 10/21] Xen-paravirt: Name: dont export paravirt_ops structure, do individual functions

Jeremy Fitzhardinge wrote: Wrap the paravirt_ops members we want to export in wrapper functions. Since we binary-patch the critical ones, this doesn't make a speed impact. I moved drm_follow_page into the core, to avoid having to wrap the various pte ops. Unlining kernel_fpu_end and using that