Keir Fraser wrote:
On 16/2/07 17:10, "Keir Fraser" [off-list ref] wrote:
quoted
On 16/2/07 16:46, "Jeremy Fitzhardinge" [off-list ref] wrote:
quoted
Yes, that would work. Unfortunately that's i386 arch-specific, whereas
the rest of this code is generic. I guess I could just move it all to
arch/i386/mm.
This whole thing isn't an issue on ia64 (they no-op lock_vm_area) and
powerpc doesn't use any of the Xen driver code at this time.
vmalloc_sync_all is supported by both i386 and x86_64, so we can make the
call conditional on CONFIG_X86 so that ia64 will continue to build. This is
what I've done in xen-unstable.
In fact that file is only built for i386 and x86_64, so there really is no
problem with using vmalloc_sync_all() directly and without ifdef.
I had moved it to mm/vmalloc.c in response to previous review comments
(namely, its not Xen specific, so it shouldn't live in the Xen part of
the tree).
J
On 16/2/07 17:27, "Jeremy Fitzhardinge" [off-list ref] wrote:
In fact that file is only built for i386 and x86_64, so there really is no
quoted
problem with using vmalloc_sync_all() directly and without ifdef.
I had moved it to mm/vmalloc.c in response to previous review comments
(namely, its not Xen specific, so it shouldn't live in the Xen part of
the tree).
Then the call will have to be CONFIG_X86. I hadn't realised powerpc were
also using lock_vm_area. However I suspect that the x86 issue that those
functions were written doesn't even exist on powerpc, or any other non-x86
architecture.
I guess we should change the name of alloc_vm_area, by the way. Perhaps
alloc_vm_area_sync() or similar, to give some hint of what it's doing and
how it differs from other vmalloc-area functions?
-- Keir
On 16/2/07 17:27, "Jeremy Fitzhardinge" [off-list ref] wrote:
In fact that file is only built for i386 and x86_64, so there really is no
quoted
problem with using vmalloc_sync_all() directly and without ifdef.
I had moved it to mm/vmalloc.c in response to previous review comments
(namely, its not Xen specific, so it shouldn't live in the Xen part of
the tree).
Then the call will have to be CONFIG_X86. I hadn't realised powerpc were
also using lock_vm_area. However I suspect that the x86 issue that those
functions were written doesn't even exist on powerpc, or any other non-x86
architecture.
I guess we should change the name of alloc_vm_area, by the way. Perhaps
alloc_vm_area_sync() or similar, to give some hint of what it's doing and
how it differs from other vmalloc-area functions?
-- Keir