From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Creekmore Subject: Re: [PATCH v4 2/5] build: Hook the schedulers into Kconfig Date: Sat, 09 Jan 2016 16:47:42 -0600 Message-ID: References: <1452288166-43501-1-git-send-email-jonathan.creekmore@gmail.com> <1452288166-43501-3-git-send-email-jonathan.creekmore@gmail.com> <56911EAA.8030707@citrix.com> <56914CBB.2050406@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aI2Ie-0004K6-PF for xen-devel@lists.xenproject.org; Sat, 09 Jan 2016 22:47:57 +0000 Received: by mail-yk0-f195.google.com with SMTP id a85so25437806ykb.2 for ; Sat, 09 Jan 2016 14:47:45 -0800 (PST) In-reply-to: <56914CBB.2050406@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: George Dunlap , Jonathan Creekmore , Dario Faggioli , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org Andrew Cooper writes: > On 09/01/16 17:50, Jonathan Creekmore wrote: >> Andrew Cooper writes: >> >>> On 08/01/16 21:22, Jonathan Creekmore wrote: >>>> +# Enable schedulers >>>> +menu "Schedulers" >>>> + visible if EXPERT = "y" >>>> + >>>> +config SCHED_CREDIT >>>> + bool "Credit scheduler support" >>>> + default y >>>> + ---help--- >>>> + The traditional credit scheduler is a general purpose scheduler. >>>> + >>>> + If unsure, say Y. >>>> + >>>> +config SCHED_CREDIT2 >>>> + bool "Credit2 scheduler support (EXPERIMENTAL)" >>>> + default y >>>> + ---help--- >>>> + The credit2 scheduler is a general purpose scheduler that is >>>> + optimized for lower latency and higher VM density. >>>> + >>>> + If unsure, say Y. >>>> + >>>> +config SCHED_RTDS >>>> + bool "RTDS scheduler support (EXPERIMENTAL)" >>>> + default y >>>> + ---help--- >>>> + The RTDS scheduler is a soft and firm real-time scheduler for >>>> + multicore, targeted for embedded, automotive, graphics and gaming >>>> + in the cloud, and general low-latency workloads. >>>> + >>>> + If unsure, say N. >>>> + >>>> +config SCHED_ARINC653 >>>> + bool "ARINC653 scheduler support (EXPERIMENTAL)" >>>> + default y >>>> + ---help--- >>>> + The ARINC653 scheduler is a hard real-time scheduler for single >>>> + cores, targeted for avionics, drones, and medical devices. >>>> + >>>> + If unsure, say N. >>> Sorry for not noticing this before. The "If unsure, say $X" should >>> really match the default value. >>> >>> On the other hand, given that we are hiding all these options behind >>> CONFIG_EXPERT, I am not sure that we need "If unsure" clauses. Anyone >>> who isn't sure shouldn't have turned on CONFIG_EXPERT to start with. >> I was trying to mimic language that the Linux kernel would use for >> EXPERIMENTAL marked items. Given the documentation on the wiki, I think >> marking those three schedulers EXPERIMENTAL is correct. > > I concur about their status. > >> Given that, I >> still think that the language saying "If unsure, say N" is correct (the >> thought being, the only people who should be messing with the >> EXPERIMENTAL schedulers are people developing or specifically testing >> them). The *only* reason I marked them default of Y is to keep backwards >> compatibility with the current build. > > Also very important. > >> >> However, if you would prefer me to remove the "If unsure" language >> completely, I can do that. The text came in before the whole >> CONFIG_EXPERT flag did. > > I would suggest dropping it (although you probably want to wait for > opinions from others). We have already diverged from Linux with regards > to the EXPERT flag; people who are unsure cannot accidentally get here. OK, if I haven't heard anything from any others by the time I send out my v5 on Monday with the other items you caught, then I will go ahead and remove the language.