linux-kernel - Re: about modularization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 07 Aug 2007 01:35:33 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Mitchell Erblich <erblichs@...thlink.net>
CC:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	"T. J. Brumfield" <enderandrew@...il.com>
Subject: Re: about modularization

On 08/06/2007 11:48 PM, Mitchell Erblich wrote:

> Of the uni-processor systems currently that can run Linux, I would not 
> doubt if 99.9999% percent are uni-cores.

s/can// and I would. s/uni-processor// additionally and I'd assure you it's 
untrue. s/uni-cores/non-smt uni-cores/ and I'd do the same.

> It will be probably 3-5 years minimum before the multi-core processors
> will have any decent percentage of systems.

Which is also approximately the same timeframe in which one might consider 
currently developped kernels obsolete for deployment by the way...

> And I am not suggesting not supporting them. I am only suggesting is wrt
> the schedular, bring the system up with a default schedular, and then
> load additional functionality based on the hardware/software requirements
> of the system.

But why? First, look at the number of #ifdef CONFIG_SMP in the scheduler 
code -- the Linux kernel already has seperate UP/SMP schedulers selected 
through CONFIG_SMP. Embedded can certainly use its own !CONFIG_SMP kernels, 
for Linux servers SMP is the norm today and for the desktop/home, SMP 
probably already _also_ is the norm today, what with multi-core and HT 
(which needs different things than real SMP does, but is also certainly not 
UP). And if it isn't, it will be tomorrow and stay that way for the 
forseeable future.

[ snip ]

> IMO, if their is a fault (because of heat, etc) the user would rather 
> bring up the system in a degraded mode. Same reason applies to... boot
> -s..

To what? I don't understand this comment. You are optimizing for the case of 
a dead CPU? Why would the user care if he'd be running the most optimal 
scheduler for the situation when his box is limping along anyway?

Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/