[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 Thu, 2016-01-07 at 15:00 +0000, Ian Campbell wrote: > On Thu, 2016-01-07 at 07:37 -0700, Jan Beulich wrote: > > > > > On 07.01.16 at 15:01, <jonathan.creekmore@xxxxxxxxx> wrote: > > > > > Ian Campbell writes: > > > > > > > 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. > > > > > > So, if I add a patch in a v3 of this series that introduces a > > > CONFIG_EXPERT option and hides all of the scheduler options behind that, > > > would that be acceptible? That is a proposal that was mentioned on this > > > thread before. > > Thinking about it I think I'd avoid the specific name CONFIG_EXPERT due to > the expectations which Linux's use of the name has set. > > If we invert the sense then we could call it e.g. CONFIG_STANDARD_PLATFORM > and default it to y, I expect it will be easier to discourage people from > turning such an option off than to discourage them from turning something > like CONFIG_EXPERT on. Some proposed text for discussion: config STANDARD_PLATFORM bool "Standard/Supported Platform" default y help This option enables everything which is part of the standard and supported Xen platform. You should say 'Y' to this question. Turning off this option will expose additional options which will cause the resulting Xen binary to deviate from the supported configuration. Resulting configurations are not support by the Xen Project. Specifically configurations which disable this option: : * are not tested by the Xen Project; If you disable this option you should perform your own QA. * are not Supported by the Xen Project; Guidance will be given but ultimately you are responsible for fixing the issues you discover. * do not receive security support; Issues which are seen only with the option disabled are not treated as security bugs and are not subject to the security process http://www.xenproject.org/security-policy.html ). Again, you should say 'Y' to this question. Too much? In particular is the second half of each bullet over egging the pudding somewhat? The state of this option should be logged during boot. Somewhere in this lot I suppose: (XEN) Xen version 4.7-unstable (osstest@bad) (gcc (Debian 4.9.2-10) 4.9.2) debug=y Mon Nov 30 10:33:03 UTC 2015 (XEN) Latest ChangeSet: Thu Nov 26 16:01:27 2015 +0100 git:b1d398b Either "Platform: Standard" or "Platform: Custom" perhaps? The first line is too long already so standard=y|n doesn't really work. NB I don't think the logs should make a big song and dance about STANDARD_PLATFORM=n, since I appreciate that people may want to ship such things Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |