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
|
Home