|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Re: user/hypervisor address space solution
On 17 Feb 2006, at 05:39, Hollis Blanchard wrote:
Should be called get_guest/put_guest/copy_from_guest/copy_to_guest.
Better names, and the arch-specific old functions can still keep
their old names.
I don't think I understood your full meaning before, but I'm with you
now. get/put_user() will still exist on x86 and mean virtual addresses
(kernel or user). The new get/put_guest_offset() implementations will
be equivalent.
PowerPC will implement get/put_guest_offset(), but will not implement
get/put_user() at all. If those latter calls do make their way into
common code (after the PPC code has been merged), every PPC build in
the regression test suite will fail, so the patch will be flagged as
bad and not committed.
This sounds fine to me, other than that bit about confusing the word
"user" to mean "virtual" (since it could of course be a kernel address
as well).
I actually managed to get rid of get/put_user from common code, so we
only need replacements for copy_to/from_user.
I suggest e.g., copy_to_guest(handle, offset, xen_ptr, nr_items)
where handle is a 'guest pointer' of type foo *, which we view as
pointing at an array of foos. 'offset' is the offset into the foo array
to start copying to. xen_ptr must be of type foo *; it is the start
address to copy from. nr_items is the number of foos to copy.
There are a few other thgings to consider too. We could have
copy_array_to_guest with the above declaration, and have a simpler
copy_to_guest with no 'nr_items' parameter. We will need
__copy_to_guest alternatives where the handle has been pre-validated.
How does that sound?
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|