All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: Con Kolivas <kernel@kolivas.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Chris Han <xiphux@gmail.com>,
	William Lee Irwin III <wli@holomorphy.com>,
	Jake Moilanen <moilanen@austin.ibm.com>
Subject: Re: [PATCH] plugsched - update Kconfig-1
Date: Mon, 14 Nov 2005 09:52:13 +1100	[thread overview]
Message-ID: <4377C39D.2080602@bigpond.net.au> (raw)
In-Reply-To: <200511132030.36777.kernel@kolivas.org>

Con Kolivas wrote:
> On Sun, 13 Nov 2005 20:10, Peter Williams wrote:
> 
>>Con Kolivas wrote:
>>
>>>On Sun, 13 Nov 2005 16:22, Peter Williams wrote:
>>>
>>>>Con Kolivas wrote:
>>>>
>>>>>On Sun, 13 Nov 2005 12:34, Peter Williams wrote:
>>>>>
>>>>>>1. Make the ability to select which schedulers are built in independent
>>>>>>of EMBEDDED.
>>>>>>2. Only offer builtin schedulers as choice for the default scheduler.
>>>>>>3. Only build in ingosched if PLUGSCHED is not configured.
>>>>>
>>>>>I disagree with 3. Surely people might want to build in only one
>>>>>scheduler that is not ingosched without other choices.
>>>>
>>>>Yes, and they would be able to do that by selecting PLUGSCHED and then
>>>>selecting only the scheduler that they want.  But this then leads to the
>>>>observation that PLUGSCHED is probably makes things unnecessarily
>>>>complex and all that is required is a means to select the schedulers to
>>>>be built in and a choice of default (much like for the IO schedulers)?
>>>
>>>Indeed it may be better to remove the "plugsched" option entirely. Once
>>>patched in it's not like you are building the kernel without the
>>>plugsched infrastructure. Provided each extra scheduler does not increase
>>>the kernel size too much (and a test build with/without all schedulers
>>>should tell you that), it may be best to just have the scheduler choice
>>>in the top menu and only expose the "schedulers to build in" under
>>>embedded.
>>
>>I can't see why this should be restricted to embedded systems?
> 
> 
> It's just convention that size options go in there; it's not really just for 
> embedded systems.

OK.  I guess I'm sometimes guilty of taking things too literally :-(

I'll read up on Kconfig again before I make any changes.

Thanks
Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

      reply	other threads:[~2005-11-13 22:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-14  0:55 [ANNOUNCE][RFC] PlugSched-6.1.3 for 2.6.13 and 2.6.14-rc4 Peter Williams
2005-10-29  2:35 ` Peter Williams
2005-11-07 22:01 ` Peter Williams
2005-11-11  3:00 ` [PATCH] Staircase v13 for plugsched 6.1.3 Con Kolivas
2005-11-13  1:36   ` Peter Williams
2005-11-11  3:05 ` [PATCH] plugsched - update Kconfig Con Kolivas
2005-11-11  3:11   ` Con Kolivas
2005-11-11  3:17   ` [PATCH] plugsched - update Kconfig-1 Con Kolivas
2005-11-13  1:34     ` Peter Williams
2005-11-13  1:44       ` Con Kolivas
2005-11-13  5:22         ` Peter Williams
2005-11-13  5:37           ` Con Kolivas
2005-11-13  9:10             ` Peter Williams
2005-11-13  9:30               ` Con Kolivas
2005-11-13 22:52                 ` Peter Williams [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4377C39D.2080602@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=moilanen@austin.ibm.com \
    --cc=wli@holomorphy.com \
    --cc=xiphux@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.