From: Russell King <rmk@arm.linux.org.uk>
To: Robert Love <rml@tech9.net>
Cc: Adrian Bunk <bunk@fs.tum.de>,
"Robert P. J. Day" <rpjday@mindspring.com>,
Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: observations on 2.5 config screens
Date: Wed, 8 Jan 2003 00:14:36 +0000 [thread overview]
Message-ID: <20030108001436.A14505@flint.arm.linux.org.uk> (raw)
In-Reply-To: <1041982936.694.786.camel@phantasy>; from rml@tech9.net on Tue, Jan 07, 2003 at 06:42:16PM -0500
On Tue, Jan 07, 2003 at 06:42:16PM -0500, Robert Love wrote:
> On Tue, 2003-01-07 at 18:30, Adrian Bunk wrote:
> > Robert, could you comment on whether it's really needed to have the
> > preemt option defined architecture-dependant?
> >
> > After looking through the arch/*/Kconfig files it seems to me that the
> > most problematic things might be architecture-specific parts of other
> > architecturs that don't even offer PREEMPT and the depends on CPU_32 in
> > arch/arm/Kconfig.
>
> I think it should be there. Plus, as you say, it is defined
> per-architecture.
>
> The real problem in my opinion is that the category is misnamed. It is
> not "processor options" except for the first couple. The majority of
> the options should be under a title of "core" or "architecture" or
> "system options" in my opinion.
On ARM, it doesn't appear under "processor options" but under
"General Setup", which is where it fits best, along with the other
general core features of the kernel. It does depend on a processor
option, but there should not be any problem with that. ARM _does
not_ support preempt on 26-bit ARM CPUs, so we _explicitly_ disallow
selection of that configuration.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
next prev parent reply other threads:[~2003-01-08 0:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-01 19:55 observations on 2.5 config screens Robert P. J. Day
2003-01-01 20:07 ` Tomas Szepe
2003-01-01 20:15 ` Robert P. J. Day
2003-01-01 20:26 ` John Bradford
2003-01-02 1:55 ` Randy.Dunlap
2003-01-02 2:32 ` Robert P. J. Day
2003-01-02 4:10 ` Randy.Dunlap
2003-01-02 2:54 ` Tomas Szepe
2003-01-07 23:07 ` [2.5 patch] MODULE_FORCE_UNLOAD must depend on MODULE_UNLOAD Adrian Bunk
2003-01-08 12:05 ` Rusty Russell
2003-01-07 23:30 ` observations on 2.5 config screens Adrian Bunk
2003-01-07 23:42 ` Robert Love
2003-01-08 0:14 ` Russell King [this message]
2003-01-08 14:32 ` Bill Davidsen
2003-01-08 15:53 ` Robert Love
2003-01-08 18:36 ` Bill Davidsen
2003-01-08 19:50 ` Dave Jones
2003-01-08 22:49 ` Bill Davidsen
2003-01-09 12:50 ` Dave Jones
2003-01-09 16:12 ` Bill Davidsen
2003-01-09 13:38 ` Ruslan U. Zakirov
[not found] <Pine.LNX.4.44.0301011435300.27623-100000@dell.qualified-at.bofh.it>
2003-01-02 23:50 ` Bill Davidsen
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=20030108001436.A14505@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=bunk@fs.tum.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@tech9.net \
--cc=rpjday@mindspring.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox