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@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
