Re: [Xen-devel] [Hackathon Minutes] Xen 4.4 Planning

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Friday, June 14, 2013, 11:59:35 AM, you wrote:

> Hi all,

> I will go through the thread and try and answer question (where they have
> not been answered and discussed), but will need the help of the people who
> actually attended and drove the discussion at the Hackathon. I merely took
> notes of what was said, and at times I missed things.

> And no decision of any kind has been made : for this we do have a decision
> making process. But this thread seems to show that we do have a number of
> problems that need fixing. Maybe we need to crystallize this a little more.

>>From Jan:
>> From the summary above I didn't really get what's wrong with the current
> 9 month cycle, which ...
> I don't think this was indeed covered. I think the rationale was really
> covered in the thread. I also think I minuted the 2-3 weeks + 3 months
> wrong (which seems to have been clarified).

>>From Ben Guthro:
>> Did you have any more info on this bullet, and the other one below Re: 
>> XenClient
> / VirtualComputer?
> The only thing I remember was that this discussion was originally started
> by George and that IanC, Konrad, Stefano and Matt mostly covered it. We do
> seem to have a problem with PCI passthrough - Pasi's points. Maybe they
> recall more detail.

> I also wanted to add to the point that Alex has made on serious bugs in xen
> vs. kvm : this gets raised regularly by Xen users when I attend
> conferences. And I also heard a few times now that we appear to focus more
> on sexy features rather than the basics. This is relatively new though: the
> first time I noticed was towards the end of last year. Which does not mean
> that this is new: it may just mean that top issues/concerns that were
> frequently raised before (mainly trust in the future of the project) have
> disappeared.

One of the things mentioned below is the "break dom0", i think KVM has some 
advantage here.
They could learn from the "mistakes" from Xen and make a new implementation 
from the ground up.

One of the causes could be that the Xen project has had to make a giant leap on 
multiple fronts from the "(forced) choice / mistake (in hind sight perhaps)"
to fork the Kernel and Qemu. Not to forget the tool-stack change that are also 
underway ...
Especially since that leap had to be made on multiple fronts at once and has 
it's interdepencies everywhere.

In the mean time there is still the wish and effort to not go and lag behind 
feature-wise as well (arm port).

Xen still seems to lag somewhat behind, although it doesn't need a seperate 
"special" Xen kernel anymore
since the PV parts have been upstreamed. But the giant leap, limited resource 
and wish to keep PV and functionality on par at one side,
and the views and interest of the Linux community and maintainers on the other 
side seems to have:

1) Disgruntle some Linux maintainers
2) Made code and interfaces not always clean and well documented
3) Not always uses the current kernel interfaces in the ways it was expected 
(by the authors/maintainers)

Which causes:
1) It makes patches from authors not familiar with Xen break things, this often 
happens in the merge window.
2) Maintenance burden, it requires quite some effort to keep up with the impact 
of (non primarily xen-targeted) changes in Linux and Qemu (which can't be 
invested in nice new features)
3) A lot of legacy stuff perhaps hinders the way forward ...

I must say Konrad does a tremendous job of keeping things together here and is 
*very* responsive !
I know Konrad is trying to clean this all up, refactor and document, but i 
think his time is split between quite some tasks and kernel parts.

One of the things I question is the need to still support machines without 
hardware virtualization ?
- Yes, it's one of the main features compared to f.e. KVM
- No, 32bit support seems to be on it's way out, although there are (intel) 
64bit processors without hardware virtualiztion, is that worth the effort ?

But there doesn't seem to be a "architectural-roadmap", which not only tells 
"WHAT features", but is more orientated on (desirably) "HOW to implement / 
refactor / reimplement" ?
(so the grant-scheme of things so to say, and perhaps there can be things 
learned from KVM now ?)



Could a shorter development cycle, together with more focus, get things going 
faster ?

Perhaps the key is in more focus, focus can be seen in two ways:
1) focus of the complete release cycle (as a "theme"), f.e. do a tick-tock, 
tick=feature release cycle, tock=cleanup, code refactoring.
2) focus at front of which (limited number) of main features or cleanups the 
cycle focusses on, and make sure there is enough man-power in reserve to get 
these done.
   Any other feature can be included, but won't be commited unless in such a 
state that is well tested and will "guarantee" to not make the release date 
shift.
   For the chosen mean features, it could be a debian style release when ready 
and happy. The cleanup/refactoring release cycle could be shorter, but will 
probably need more
   synchronization with the 2 main dependencies (linux/qemu) projects.

So one release cycle would focus on new Xen-features and implements them in Xen 
and related projects (inside->out),
the second release cycle focuses on cleaning up legacy and refactoring, 
cleaning up code and tries to relieve the maintenance burden especially with 
the related projects (outside->in).

Perhaps this could suppress incomplete code and incomplete features between 
releases somewhat.

Unfortunately, i'm not that good of a low-level programmer, that my efforts 
would contribute much code wise,
but i try to contribute by testing new kernels early during the development 
cycle.
(in the hope it's easier to pinpoint the changes causing the bug and maximizing 
the time to fix things up)

Just my few cents ...

P.S.: I think the Xen community is quite responsive and nice to work with, and 
Xen as a whole works great for me :-)



--
Sander


> Lars


> On Fri, Jun 14, 2013 at 9:15 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:

>> >>> On 13.06.13 at 23:03, Alex Bligh <alex@xxxxxxxxxxx> wrote:
>> > The thing we like the second least about Xen is how long it seems to take
>> > to get what we count as serious bugs fixed, even in stable releases.
>>
>> I think applicable bug fixes get applied to the stable branches in
>> quite timely a manner, at least on the hypervisor side. Hence I
>> can only assume that you're unhappy with the rate of stable
>> releases. Yet I don't think we're going to get anywhere near of
>> the almost weekly stable releases that get done for Linux. As
>> you also didn't say what expectations you really have, it's hard
>> to take out anything useful from that complaint.
>>
>> > We like it even less if we have to find them and fix them.
>>
>> But isn't that how open source projects work - everyone contributes
>> and fixes bugs. If you don't want to help fixing bugs, I'm afraid
>> there's also no good reason for you to complain they don't get fixed.
>>
>> > By 'serious' I mean basic functionality not working, crashes dom0, etc.
>>
>> When did we last break Dom0, and not fix it in a timely manner?
>>
>> > The result of this is two-fold. Firstly, we've never (yet) been able to
>> > run a production version of xen which is a standard xen release. We've
>> > always had to maintain our own patches even on 'stable' releases.
>> > Frankly, this is a pain.
>>
>> But if you don't contribute back your patches, how do you expect
>> them to get accepted/merged? Or are you saying that it's _far_
>> more than occasional that patches from you get entirely lost?
>>
>> Jan
>>
>>


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