Re: [PATCH 00 of 27] Refactor libkvm code Phase 1

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Jerone Young wrote:
> Hmm,
> 	The problem here is in the case of kvm_create_phys_mem &
> kvm_create_default_phys_mem, most archs from now on should always be
> allocating guest memory from userspace (at least I think this correct).
>
> 	Now if this is not the case then really adding an architecture hook
> function to kvm_create_default_phys_mem would also solve this problem.
> As There is a mmap call that maps memory for video(?), which is
> something that is just for x86.
>
> 	With the size of these functions being very small, I think it's best to
> move them for now. Then if someone else does need them they can easily
> create there own and then we can figure out how to make a common
> function in this case.
>
> 	Anyone disagree?
>   

Me.  Let's not copy and re-unify needlessly.

If the create_kernel_memory() thing is a problem, define a function for 
non-x86 that returns -ENOSYS.  It won't be called anyway.

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/