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 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 thought about generic PV
support and we're not just trying to dump a bunch of Xen-only code into
the tree.
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
--
Alex Williamson HP Open Source & Linux Org.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home