[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-users] Re: Xen is a feature
Thomas Gleixner wrote: I can appreciate the idea of resisting the pushing of random features. Still, your definition of "improving Linux" is still lacking. Obviously a new scheduler is taking something that's existing and improving it. But adding a new filesystem, a new driver, or adding a new feature, such as notifications, AIO, a new hardware architecture, or even KVM: How do those classify as "technical improvement to the kernel" or "features which have technical benefit to the code base" in a way that Xen does not?Exactly that's the point. Adding dom0 makes life easier for a group of users who decided to use Xen some time ago, but what Ingo wants is technical improvement of the kernel. There are many features which have been wildly used in the distro world where developers tried to push support into the kernel with the same line of arguments. The kernel policy always was and still is to accept only those features which have a technical benefit to the code base. If you mean "increases Linux's technical capability", and define Xen as outside of Linux, then I think the definition is too small. After all, allowing Linux to run on an ARM processor isn't increasing Linux' technical capability, it's just allowing a new group of people (people with ARM chips) to use Linux. It's the same with Xen. No one disputes the idea that changes shouldn't be ugly; no one disputes the idea that changes shouldn't introduce performance regressions. But there are patchqueues that are ready, signed-off by other maintainers, and which Ingo admits that he has no technical objections to, but refuses to merge. (His most recent "objection" is that he claims the currently existing pv_ops infrastructure (which KVM and others benefit from as well as Xen) introduces almost a 1% overhead on native in an mm-heavy microbenchmark. So he refuses to merge feature Y (dom0 support) until the Xen community helps technically unrelated existing feature X (pv_ops) meets some criteria. So it has nothing to do with the quality of the patches themselves.) [Not qualified to speak to the specific technical objections.] If Joe User uses Amazon, he benefits. If Joe User downloads an Ubuntu or Debian distro, and the hosting providers were more secure and had to do less work because dom0 was inlined, then he benefits because of the lower cost / resources freed to do other things.I really have a hard time to see why dom0 support makes Linux more useful to people who do not use it. It does not improve the Linux experience of Joe User at all. But what I was actually talking about is the number of people who don't use it now but would use it if it were merged in. There hundreds of thousands of instances running now, and more people are chosing to use it at the moment, even though those who use it have the devil's choice between doing patching or using a 3-year old kernel. How many more would use it if it were in mainline? No one is asking for something to be merged in a crappy way, or with unacceptable performance cost. There are a number of patchqueues that Ingo has no technical objections to, but which he still refuses to merge.In fact it could be harmful to the average user, if it's merged in a crappy way that increases overhead, has a performance cost and draws away development and maintenance resources from other areas of the kernel. "Drawing away development and maintenance resources" is a cost/benefits question, and Jeremy's main point was that there is a *high* benefit for dom0 being merged into mainline. The same could be said of almost anything: are you suggesting not accepting any more KVM code because it might "draw away development and maintenance resources from other areas of the kernel"? This argument doesn't make any sense. Would you advocate only having one filesystem for fear that people would somehow be discouraged from working on a new filesystem?Aside of that it can also hinder the development of a properly designed hypervisor in Linux: 'why bother with that new stuff, it might be cleaner and nicer, but we have this Xen dom0 stuff already?'. Even if that were a valid argument, it wouldn't apply in this situation. KVM has plenty of mind-share, and the support of RedHat. Also, I'd wager that it's a lot easier for a Linux kernel developer to get involved in KVM than in Xen, because they're already familiar with Linux. I don't think anyone working on KVM will be tempted to give up just because Xen is also available, unless it becomes clear that linux-as-hypervisor isn't the best technical solution; in which case, moving to Xen would be the right thing to do anyway. Merging dom0 Xen will in no way interfere with the development of KVM or other linux-as-hypervisor projects. The main point of Jeremy's e-mail was NOT to say, "Lots of people use this so you should merge it." He's was responding to Xen being treated like it had no benefit. It does have a benefit; it is a feature. -George _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |