[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 0/4] Allow schedulers to be selectable through Kconfig
On Fri, 2015-12-18 at 11:56 -0600, Doug Goldstein wrote: > In the end I really see the primary people that build Xen on their own > as project maintainers (XenServer, Qubes, OpenXT) or distro maintainers > (Ubuntu, Debian, Gentoo, Yocto) or "expert" users. Most people will use > Xen as it comes packaged for them already and the Kconfig changes give > the project/distro/experts the flexibility they need to build up Xen > without maintaining downstream patches. So these won't really be shiny > knobs for users to twiddle. In this context I would consider the distro maintainers (at least for generic, non-Xen specialised distros, e.g. XenServer and QUBES don't fit here) to be users. I don't think we want such distros to all be shipping subtly varying versions of Xen any more than I want individual end users to be doing so. Users of community (rather than Enterprise/Commercial) distros use many of our upstream resources, including reporting bugs on xen-users and -devel. But of course you (quite naturally, I think) expect that they will want to play with these things, and I think that they will be no less prone to fiddling with the shiny nobs than a individual user would be. I don't want to distro users coming to use for support because they tried to followÂhttp://wiki.xenproject.org/wiki/Credit2_Scheduler_Development#Usi ng_Credit2Âand it didn't work, only to find that their distro has decided to turn off credit2 in the packages, for whatever random reason the package maintainer had. I don't see this as contrary to your stated goals (e.g. ripping out all the other schedulers), but I consider you to be within the expert camp for wanting to do so (and having the chops to handle whatever pieces you find yourselves with). I have no objections at all to allowing experts such as yourselves to configure things and I applaud you for doing this in an upstream way (it is the right thing to do). My concern is that while you rightly consider yourselves expert enough and are building something for a specific (and AIUI targeted) use case many normal users tend to think that if they are expert enough to find and flip the switch then they are expert enough to deal with the consequences, when they are not and/or they do not have the specific use case which the switch was added to support i.e. they want common or garden Xen and we want that to mean the same for everyone. It's those people (including general purpose distro maintainers) who I think need to be strongly discouraged from messing with these options because there will be a strong gravity towards them doing so. > What provides the defaults that users should use are the defconfig > files. The reason this doesn't work out so well for Linux is that there > are really not defaults that work for everyone. ... and sadly by switching Xen to Kconfig this expectation _is_ going to flow over to us, once someone sees "make menuconfig" mentioned somewhere they are going to get their Linux head on and start messing with it. > ÂBut on the flip > side of the coin Ian Campbell has been helping Debian to upstream > changes they need [2]. BTW, I'mÂalso a Debian Developer (although not the Xen package maintainer), so I am doing this with as much downstream as upstream hat on. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |