|
|
|
|
|
|
|
|
|
|
xen-ia64-devel
RE: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps
On Mon, 2008-03-10 at 13:56 +0800, Dong, Eddie wrote:
> Alex & all:
> I exchanged some ideas with Isaku to discuss the gap and status
> of pv_ops support in IA64, Isaku did a lot of work toward pv_ops since
> his previous forward backport patch. Great thanks to Isaku.
> The attached doc is a draft for some of the key gaps and current
> status. I think it is time for another cross major company meeting to
> discuss how we cooperate and how effectively go with pv_ops. Mostly
> Isaku and I are in same page for what IA64 pv_ops should look like now,
> though some details may have different understanding.
>
> Any ideas?
Hi Eddie,
Much thanks to you and Isaku for leading this effort. I'm open to
another conference call, but maybe we can discuss some items here on the
mailing list too. I saw that Isaku has created a wiki page on the Xen
wiki and started a new git project on Gitorious.org. The wiki page
seems like a good place to keep track of who is working on which chunk
and the status. For the git side, I would suggest that the model might
be that each developer has a project on gitorious.org and sends out
patches or pull requests to have a single "upstream" reference. Isaku's
tree seems to be a good focal point for now if he's willing to take on
the task of accepting code from others.
The 2.6.26 merge window will likely open before too long, so we also
need to do some coordination with Tony Luck and the other upstream
developers. Are they going to be interested in putting in pieces at
each upstream merge window, or should we build up a complete solution
for domU support in Isaku's tree or Tony's testing branch first? We
also need to be careful about submitting patch sets that stand on their
own and are bisect-able. It's likely going to take several kernel merge
windows before we get full domU support, let alone dom0.
In your slide set, you mention removing running_on_xen since it
conflicts with pv_ops. I think this is a really good goal, but I have
doubts about whether it's achievable. We're not likely to make a pv_ops
to fit every corner case, and we may have to resort to an ugly direct
test for xen. Let's try to avoid them, but we already have a few cases
of checking machine vector names for this type of thing in other parts
of the ia64 code. 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
|
|
|
|
|