WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [PATCH] linux/netback: save interrupt state in add_t

 >>> On 15.09.10 at 22:58, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> On 09/14/2010 02:26 AM, Jan Beulich wrote:
>> Nor can I foresee when the pv-ops tree will be reliable enough
>> and sufficiently functionally complete (without hacks that in
>> some cases I think are worse than those in the 2.6.18 tree) to
>> be used as the basis of an enterprise Dom0 (which is the
>> criteria that could make us finally do the long hoped for switch).
>>
> 
> I'd be interested to know what you have in mind here.

One missing bit of functionality that I can think of right away are
the GNTST_eagain retry loops needed for Xen's paging (and
perhaps also memory sharing). I looked for them maybe a week
ago, and didn't find any of them - did I perhaps just look in the
wrong branches (see below)?

Others coming to mind without much looking around would be
pv-scsi, pv-usb, and the accelerator parts of netfront/netback.

A second aspect is the multitude of branches all in different
feature and maintenance states. A stable 2.6.32 tree as some
sort of main branch is nice, but insufficient for the purpose of
integration when our main tree tracks upstream very closely
(switching usually around -rc2). Having otoh several dozen
branches (some in an apparently forgotten about state) with
features and fixes scattered around isn't very helpful either.

As to the hacks - from what I saw I'm not certain I can create a
non-Xen kernel from any of the branches that would be (close
to) binary identical with one created from the respective upstream
(or stable) kernel. I'm not even certain it would build. But then
again I'm judging only from looking at it, not from really having
tried.

Especially the ACPI stuff introduced Xen-specific (parts of) files
outside of drivers/xen/ that I thought would be a no-go in the
pv-ops tree.

Finally, I'm continuing to see way too many "does not work" mails
on xen-devel.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel