Alex Williamson wrote:
> 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
Since we are unable to get whole solution (dom0) to upstream in
near future since X86 didn't complete it yet. OSV are unable to build
single image for all, so I think they may stay with current solution
a little bit longer till X86 get solved. I am not that care about
which version IA64 pv_ops will be in. As if Tony starts to take the
patch,
the rest will be easy.
> 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
Yes, we need to get clear message firstly. In the doc, I was assuming
maintainer need to see whole patch, though he takes one slowly at
beginning especially.
> 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
Agree, so at least we get xen-ia64/kvm-ia64 people buy in the patch
first
so that we can push together.
> 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
My assumption is that Linux maintainer won't expect to see
running_on_xen, running_on_kvm, running_on_lguest,
running_on_hybrid_xen, running_on_hybrid_kvm etc. It is too ugly.
But if you mean we keep it temporary for now, I am fine.
> 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,
Could you point me to the code that you feel pv_ops may be hard here?
>
> Alex
Thanks, eddie
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home