[Xen-devel] RE: One question to compat model

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

>-----Original Message-----
>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>Sent: Wednesday, May 12, 2010 5:13 PM
>To: Jiang, Yunhong; Jan Beulich
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: One question to compat model
>
>On 12/05/2010 09:50, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>
>>> You can't disable CONFIG_COMPAT anymore, but I think you should
>>> be able to tweak the CONFIG_COMPAT section in
>>> xen/arch/x86/cpu/mcheck/mce.c in a way to allow your new code to
>>> be built without doing anything compat-related for the new
>>> structures. But maybe removing the domctl.h dependency already
>>> clarifies matters.
>>
>> Yes, it should be ok. But a curios question is, why the xenctl_cpumap has to
>> be defined in domctl.h. It's simply a helper function. Now I have to work 
>> like
>> XENPF_getidletime, passing two parameters (nr_cpus and the bitmap pointer),
>> combine them in hypervisor to xenctl_cpumap and then call the xenctl_cpumap
>> code. And the same to user space tools.
>
>Whoever implemented XENPF_getidletime decided to stuff a fake xenctl_cpumap
>struct within Xen rather than properly refactor the public headers. There's
>no reason not to move xenctl_cpumap out into xen.h.

A curios question. I checked the code, and notice that the XEN_GUEST_HANDLE_64 
is only defined for __XEN__ or __XEN_TOOLS__. I can understand it is needed for 
tools because 32bit tools can be used in 64bit dom0, but why it is forbidden 
for kernel? To avoid it be passed as hypercall parameter? Sorry for bothering 
if this is a stupid question :$

Thanks
--jyh

>
> -- Keir
>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel