Re: [Xen-devel] [HVM} xen_platform_pci=0 doesn't prevent platform device creation and disk and nic take over by PV drivers.

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Wednesday, October 9, 2013, 5:32:04 PM, you wrote:

> On 09/10/13 13:49, Sander Eikelenboom wrote:
>> Wednesday, October 9, 2013, 2:00:02 PM, you wrote:
>>
>>> create ^
>>> title it xen_platform_pci=0 doesn't work with qemu-xen
>>> owner it Anthony Perard <anthony.perard@xxxxxxxxxx>
>>> thanks
>> Perhaps in general looking at the libxl and xend .. and .. qemu-xen and 
>> qemu-xen-traditonal compatibility shoud be added too.
>>
>> Perhaps i'm a bit blunt ..
>> but for users it's quite a mess and PITA now for quite some time, the 
>> transition of both is now smeared out over quite some major and minor 
>> releases.
>>
>> With some features not working since .. some features are working again but 
>> have a gap of not working,
>> since old features becoming usable again are (understandably) not backported.

> Well thank you for being blunt -- we'd much rather you complain than 
> just silently disappear. :-)  I can certainly see where you're coming 
> from.  But on the flip side -- how are developers supposed to know what 
> is broken if nobody tests it, or reports it?  We had several test days 
> before the 4.3 release; if anyone had reported this feature broken, it 
> would have been fixed immediately.

Well if you do care, you can't silently disappear :-)

I know there is a almost unlimited combination of config options, so not 
everything can be tested in every combination (not by hand, and probably not by 
machine either).
However during such a refactoring one would expect that at least every option 
that can be disabled and enabled would be tested on it's own.
This one clearly wasn't nor do the docs say anything about it missing ...

I have no idea how much test resources there are available to the project, 
since there are already quite a lot of
dependencies to test.

However this makes me wonder, does the current test system have something like 
the randconfig on linux ?
Or is it always running tests on the same config ?

Hmm have to dive into those docs about OSStest then ...

> Something similar with xend -- many of the Xen developers were 
> considering removing xend for 4.4, because xl seemed to be mature enough 
> for everyone.  When we discussed it on the list, immediately a number of 
> people stood up and listed features they wanted that were missing from 
> xl, or ways in which xl didn't meet their needs.

> We're not mind-readers, and our software doesn't have a call-home 
> feature to let us know who is using what feature.  The core developers 
> have already been looking at libxl, xend, and qemu-xen for some time; we 
> made the switch because it looked like we had feature parity for the 
> important features.  Us taking a longer look at this point isn't going 
> to help things: we've seen all we're going to see.

The other part of it is that it's not documented that something is missing 
either.
So (most) users aren't mind-readers as well as code readers ;-)

The docs for example don't say all the nifty multifunction and vslot 
functionality of
pci passthrough isn't working.

> If you have features that are missing from xl/qemu-xen that are not on 
> my 4.4 development list, and not in xenbugs, the best thing you can do 
> is report them, so we can put them on our list.  Better yet, as Stefano 
> said, write a test case for them, to make sure that they are never 
> broken in any release ever again. :-)

> As for the future -- it is unfortunate that with a major transition, 
like from xend->>libxl and qemu-traditional->qemu-xen, there is going to 
> be some "catch-up" as bugs are ironed out and important functionality 
> "faulted in".  This same thing happens in other open source projects; 
> KDE, Gnome, Ubuntu's move to Unity, all come to mind as things that have 
> had this happen. Even Linux: the Linux driver for the SD card reader 
> broke on my 8-year-old laptop 4 years ago, and still hasn't been fixed.  
> KVM isn't an exception: they just haven't had to do any major 
> refactorings yet (as far as I know). Maybe that's because they have 
> superior process, developers, or design; or maybe it's just because it's 
> a younger project by about 4 years, and there's a major refactoring 
> coming up right around the corner. :-)

Yes i know Xen is running into the "Law of the handicap of a head start" now,
and KVM has had the opportunity to learn from that and eventually they will run
into that as well. How ever i think there could perhaps be some lessons in here
regarding to the release process when doing major code refactoring projects.

> I don't forsee any more big transitions like that for Xen any time on 
> the horizon: once libxl and qemu-xen settle down, things should be 
> stable for quite a while.  We're putting a lot more effort into writing 
> test cases, and making it easy for others to do so; as our test suite 
> grows and becomes more comprehensive, the number of features that can 
> get broken without us noticing will get smaller and smaller.

I could see at least one such transition lurking on the qemu-side of things.
The machine model transition from I440FX/PIIX4 to Q35 (or making the xen code 
agnostic
as seems to be done with KVM)

And the dicussion on how to proceed with PVH could lead to another one ...

>   -George
--
Sander



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel