>From: Magenheimer, Dan (HP Labs Fort Collins)
>Sent: 2006年4月20日 21:36
>
>As many of the patches that are being posted are requiring more
>and more changes to xenlinux/ia64, I would like to express a
>concern. Xen/x86 has taken many liberties with changes (primarily
>for dom0) that the Linux community has not even seen yet as
>the posted Linux patches for Xen -- and not yet accepted -- are
>the less-invasive changes for domU only.
>
>Per the attached news article, the Linux community is starting
>to express a preference for the less-invasive VMware approach
>and I fear that since we (Xen/ia64) are now following more of the
>Xen/x86 approach, we are going to need to reverse course at
>some point and back out many of the changes we are making to
>Linux because the community will never accept them.
OK, I think most efforts currently on-going in the xen/ia64 community
are agreed at last xen winter summit, like converting dom0 from p==m
to p!=m, moving iosapic from dom0 to xen, event callback, guest SMP,
etc. They are raised mainly to make up xen/ia64 infrastructure and thus
to support more common xen features, like network/balloon/driver
domain, etc. They're agreed due to those features are basic
components within Xen world, and thus people have to do necessary
changes including ones to xenlinux.
We may reverse some logic later once xen is getting cleaner interface
abstraction, but that doesn't become the resistance against current
trend by borrowing xen/x86's logic into xen/ia64. Actually it's more
difficult to reshuffle a product when different architectures have quite
different basic infrastructures. If all architectures are basically uniformed
(for those arch independent features), it's easier to make decision as a
whole.
Also it would be interesting to see such sentence: "back out MANY of
the changes ... because the community will NEVER accept them". As
Ian said in attached news, most functional units are similar with
difference mostly coming from different people developing in different
ways. When several approaches are converging, all requires relative
changes and that process is unavoidable. However that doesn't means
xen/ia64 developers have to wait simply because xen/x86 may change
in the future. We have to catch up with common features first. Along
this process, we can also help abstract xenlinux changes if necessary.
>
>All on this list know that I am a fan of "transparent
>paravirtualization"
Once again, I want to show my different view upon this "transparent".
To me, here transparent more means run-time transparent instead of
static transparent (meant code level). People are always conservative
to modify linux code, however it's worthy if the change benefits
virtualization at same time with negligible influence for native running
by same binary.
>but, in all of the early Xenlinux/ia64 paravirtualization work, I
>have also worked for "optimized paravirtualization", which minimizes
>the number of changes making only those required to maximize
>performance.
This depends on how you to define requirements.
>
>I would like to urge caution for all Xen/ia64 developers. We
>should NOT be making changes to Linux just to "increase sharing
>with Xen/x86 code" especially using the argument that we will
>"reduce maintenance efforts" as I predict, in the long run, we
>may actually be increasing our maintenance efforts.
Then we SHOULD make changes to Linux to "increase sharing with
Xen/x86 code" especially using the argument that we will "reduce
maintenance efforts" AT THE SAME TIME:
- to support more missing features claimed in xen user manual, or
- to increase performance more efficiently
And then finally improve xen/ia64 completeness.
To me, most efforts currently on xen/ia64 community are actually
following above direction.
So my point is simple: let's just do things right...
Thanks,
Kevin
>
>Just my opinion...
>
>Dan
>
>
>========
>
>http://news.zdnet.co.uk/software/applications/0,39020384,39263865,00.
>htm
>
>Linux brings VMware into the fold
>
>
>Stephen Shankland
>CNET News.com
>April 18, 2006, 11:35 BST
>
>
>Tell us your opinion
>
>As Xen makes strides into the SuSE and Red Hat kernels, the central
>Linux team is trying a more egalitarian approach
>
>Linux programmers are moving toward a change that would put
>virtualisation software from VMware on a more even footing with open
>source rival Xen.
>
>Xen was expected to be built tightly into the Linux kernel at the heart
>of the open source operating system. But Andrew Morton, a key deputy
>to
>Linux leader Linus Torvalds, is advocating an interface in the Linux
>kernel that would let it work with any virtualisation foundation.
>
>Virtualization generally refers to software and hardware that let a
>single computer run multiple simultaneous operating system instances. It
>is useful for making servers more efficient and isolating desktop
>applications into non-interfering partitions. Xen, Microsoft and VMware
>all are working on software called a hypervisor that governs how those
>virtual machines get access to the hardware resources.
>
>Morton said he prefers a neutral interface that works with any
>hypervisor, rather than the Xen-specific patch to Linux that had been
>envisioned.
>
>"For a long time, it was thought that we'd just merge the Xen patches
>as-is and be happy. But then, Linux would only run on Xen," Morton said.
>Instead, VMware programmers suggested a documented, stable
>interface
>between the kernel and the hypervisor - and they're preparing one, he
>said.
>
>"From a high-level design perspective, I think that VMware's point is a
>good one, and that a general kernel-to-virtual machine interface is a
>better thing than a Xen-only one," Morton said.
>
>XenSource and VMware both are fine with the change, but VMware gets
>a
>place at the table it lacked before.
>
>"Anything that levels the playing field for different people - that's
>going to be good for everyone, but certainly good for us as well," said
>Dan Chu, the senior director of developer products at EMC subsidiary
>VMware.
>
>The issue comes up with a new generation of "paravirtualisation"
>technology that offers better performance than VMware's current
>approach, but that requires changes to the operating system. If software
>companies adopt the kernel interface, that means that they and their
>customers won't have to worry about different versions of software for
>real or virtual machines, or different hypervisors, said Jack Lo,
>VMware's senior director of research and development.
>
>Morton said the Xen programmers haven't been active in the interface
>work. "This has been floating around for a year, and I've heard precious
>little from the Xen team on the topic," Morton said.
>
>But Xen has a similar approach to the VMware interface, called VMI, and
>the two are converging, said Xen founder Ian Pratt. "About 75 or 80
>percent of the code structures are identical. It's that common ground
>that hopefully should make its way into Linus' and Andrew's kernels
>shortly," he said. "The discussion on all of those has, I think, yet to
>begin."
>
>Part of the problem has stemmed from branding issues, Pratt said. "They
>object to putting patches into Linux having the 'Xen' prefix on all the
>function names. We're miffed about it being called VMI, since we did the
>hard work of interfaces and defining the patches," he said.
>
>VMware didn't mean for VMI to stand for VMware - it's an abbreviation
>for the generic Virtual Machine Interface - but the company is happy to
>adjust names as necessary, Lo said.
>
>The Open Source Development Labs has taken an active role in trying to
>clean up the situation, Pratt added. "OSDL has volunteered to set up
>meetings to get this stuff discussed," he said, noting they would
>possibly be set up through a virtualisation task force.
>
>How long until Xen merges?
>Morton said the Xen programmers have work to do before they can
>expect
>their patches to be incorporated into Linux. That inclusion into the
>mainline kernel makes programming and certification tasks much easier
>for Linux sellers such as Red Hat and Novell's SuSE.
>
>"I've seen little from the Xen team, period. I see that Xen has been
>snuck into Red Hat and possibly SuSE kernels, but right now I'd say it's
>a long way from making it into mainline," he said. "We really haven't
>even started looking at the code and discussing it."
>
>The merge work is being handled by programmers at Red Hat and
>Novell's
>SuSE who have closer ties with the main kernel programmers, Pratt
>said,
>adding that he's optimistic it will be uncontroversial and take place
>soon.
>
>"There's a big block of code everyone can agree on. I think that will go
>in very soon," Pratt said. "By September, I would hope that everything
>is in there."
>
>_______________________________________________
>Xen-ia64-devel mailing list
>Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-ia64-devel
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home