public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@codemonkey.org.uk>
To: Bill Davidsen <davidsen@tmr.com>
Cc: Robert Love <rml@tech9.net>, 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: Thu, 9 Jan 2003 12:50:07 +0000	[thread overview]
Message-ID: <20030109125007.GA17045@codemonkey.org.uk> (raw)
In-Reply-To: <Pine.LNX.3.96.1030108164157.23971A-100000@gatekeeper.tmr.com>

On Wed, Jan 08, 2003 at 05:49:54PM -0500, Bill Davidsen wrote:

 > > No-one other than kernel hackers should be playing with that option,
 > > hence it's in the kernel hacking menu.
 >   Anyone who wants to be able to debug a problem should be playing with
 > that

If someone is debugging a kernel, they are by definition, kernel
hacking. They should know where the kernel hacking menu is.

 > > SMP isn't a processor option ?
 >   Clearly not, it's not processor dependent or even architecture dependent

Of course its arch dependant. Some of the archs we support don't do SMP.
See m68k for one. Sure there may be some boards out there with >1 68k
welded to them, but Linux doesn't run on them.

 > generally. It's a characteristic of the os, unlike microcode, mtrr, and
 > other stuff not on some architectures.

Absolute nonsense. These are _cpu_ features. If you dispute this,
you have no understanding of what you talking about.

 > You can select it for 386/486/P5
 > (and it works in 2.4 at least, for P5, have several).

And thats perfectly valid. Although I've not seen an MP compliant
386/486 personally, there were patches I beleive at one time for
some of the strange 486 implementations.

It's also a valid thing to do to do for code coverage reasons.
Although I doubt anyones testing SMP builds on a 386/486 any more.

 >   I would think that processor options would select the processor and any
 > options which are specific to it rather than generally supported. Serial
 > numbers, firmware loads, that sort of feature.

serial number stuff is done at run time. Firmware loads. Well, you
mentioned above that microcode wasn't a CPU feature, now you change
your mind ?

 >   Preempt and smp, are general, I guess not supported on every possible
 > hardware
 
Again, more contradiction. Above you said of SMP:
"Clearly not, it's not processor dependent or even architecture dependent"
Now you're saying it is arch dependant.

Which Bill am I arguing with here ?

>From x86 POV, a preemptive SMP 386 kernel should boot.
Its the only way to guarantee that you get both features in a kernel
that will run on anything from 386 up.


		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

  reply	other threads:[~2003-01-09 12:43 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
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 [this message]
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=20030109125007.GA17045@codemonkey.org.uk \
    --to=davej@codemonkey.org.uk \
    --cc=bunk@fs.tum.de \
    --cc=davidsen@tmr.com \
    --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