RE: [Xen-ia64-devel] RE: pv_ops polish: config option & head file

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Alex Williamson wrote:
> On Tue, 2008-03-18 at 22:18 +0800, Dong, Eddie wrote:
>>>> How about just simply use CONFIG_PARAVIRT ?
>>> 
>>>    Then how do you specify that you want a kernel built with Xen
>>> support, but not KVM? 
>>> 
>> 
>> Mmm, this is kind of what level of detail do we want user to choose.
>> Given that RHEL want one image, so this sub-option is just for
>> in house development even if multiple IA64 VMM really comes.
>> We can argu for the usage model.
>> 
>> 
>> Leaving some code for this is OK, but
>> but at least for those who have running_on_xen condition already,
>> we don;t need CONFIG_XEN, (rather CONFIG_PARAVIRT).
>> Also for those Xen specific files, i.e. those xen wrapper code,
>> we can treat whole directory as one, either compile it or skip it.
>> Does this make sense?
> 
>    Hmm, I still disagree.  The way the Kconfigs are structured now, we
> have:
> 
> PARAVIRT_GUEST
>       -> PARAVIRT
>               -> XEN
> 
> PARAVIRT_GUEST adds no code, but enables the other config options. 
> XEN is dependent on PARAVIRT.  IMHO, PARAVIRT should enable the pv_ops
> functionality, but not add the Xen specific code.  You can imagine a

Yes if full pv_ops is enabled, those kind issue will all go away like
X86 side.
Actually I compromised to your suggestion to leave some running_on_xen
in code, though I still think majority of them should be pv_opsed.

With full pv_ops, running_on_xen can disappear too.

In this case, full pv_ops will solve CONFIG_XEN too, but since we may 
not have that much resource to complete it in short term, so I agree
we may leave some "CONFIG_XEN" & running_on_xen.

For those directories dedicated for XEN, I don't think we need
in code CONFIG_XEN any more.

For those running_on_xen + CONFIG_XEN case, it is a coding style issue.
Long time goal is to use full pv_ops, mca_xencomm_list is one of the
candidate IMO.

But for now leaveing runing_on_xen, or CONFIG_XEN is OK to me.
Whether it needs double condition is up to your guys.

> PV KVM option or LGUEST option that wants PARAVIRT, but not XEN (or
> all of them together in one binary).  I think which VMMs you want to
> support is a reasonable level of detail for someone configuring a
> kernel to select. The granularity also shows upstream that we've

It is always a tradeoff. If LGUEST or KVM hypervisor will come soon,
I bet full pv_ops will come soon too...

> thought about generic PV support and we're not just trying to dump a
> bunch of Xen-only code into the tree.

In this case, those mca_xencomm_list is hard to say Xen only code, it
could be abstracted as generic PV mechanism I think. But we just leave
it
to future.

> 
>    We don't need to be constantly concerned with RH's config, we need
> to look at the bigger picture for what's right in Linux.  We can make
> sure RH's config has everything we want for a single binary later as
> long as we enable that possibility in what we're doing.  Thanks,
> 
>       Alex

Thanks, eddie

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