Re: Cyrix Detection -- NO SMP, please ?????

Khimenko Victor (khim@sch57.msk.ru)
Sun, 18 Oct 1998 19:02:55 +0400 (MSD)


In <3629E2F2.B1A546D4@nb.net> Rob Dale (rob@nb.net) wrote:
RD> Khimenko Victor wrote:
>>
>> GM> First off, before you get all hot and bothered: SMP=1 SHOULD BE OFF BY
>> GM> DEFAULT!. No one SHOULD be running a SMP kernel on a non SMP box! Yes, it
>> GM> should not lockup.. But it's performance should be less. It should be no
>> GM> problem for a dist to ship two sets of kernels and modules, and a util to
>> GM> pick the right one.
>>
>> Performance issue is completely other story. Do you have util which is able to
>> find existence of second CPU when UP kernel is loaded ? Otherwise we should
>> use SMP kernel for installation CD (bootable of course :-) and this CD must
>> work for MOST users.

RD> This is a distribution issue, not a kernel issue.

No. It's kernel issue. Installation CD has image of ONE, EXACTLY ONE floppy
(1.44" -- even 2.88" not supported by all BIOS'es). Since this floppy MUST
include kernel and all drivers needed to obtain access to CD this effectively
means that this floppy could include EXACTLY ONE kernel -- SMP one since we
must detect SMP :-)

>>
>> GM> It would be nice if a kernel could work optimally on SMP and UP. This is
>> GM> not possible however, without such monstrosities as self modifying code.
>>
>> No, no, no. Not self modifying code! But we talk about different things.
>> My words: "it should work "out of box" for [almost] all users [not optimally,
>> of course]". Your answer: "it's [almost] not possible to create version which
>> will work OPTIMALLY "out of box" for [almost] all users". This is other story.
>> If you want performance you should recompile kernel with pentium or ppro
>> optimisation for start :-)) Since in most distributions kernel is compiled with
>> 386 optimisiation to ensure compatibility for example.

RD> Again, this is a distribution issue.

>> GM> No there should be seperate SMP and UP kernels. Do you think that x86 and
>> GM> Alpha should run from the same kernel binary?
>>
>> This will be great but it's almost impossible to do :-((

RD> Why would you even want to do this?
RD> Unless someone is REALLY numb to his/er surroundings,
RD> s/he will know whether or not the computer is an x86 or Alpha.
RD> But, I think this is also a distribution issue.

Yes, but if distribution will include only one butable CD for x86, Alpha, Mac,
Sparc, etc., etc. this will be great. Unfortunatelly this is impossible :-((

>> GM> The dists can simply use a setup command to pick SMP or UP..
>>
>> Dists should select right kernel automatically in most cases. Windows NT do
>> this for last few years -- why Linux could not do this ? "Joe Average" viewpoint
>> of course :-))
>>

RD> Look at what you said: Dists should select...
RD> That's exactly right! The distributions should do it.
RD> Not the kernel. This has nothing to do with the kernel.

You are wrong. It's kernel issue.
1. BEFORE distribution will select ANYTHING installation program MUST be
able to start. Since installation program is program for Linux.
2. [Almost] All features MUST be turned on by default. For one or two (SMP?)
distribution could produce special versions. Distribution COULD not include
kernels with multicasting/winthout multicastion, with IPv6/without IPv6 (when
IPv6 will not be experimental, i.e.) etc. Why ? It's simple: if you have,
for example, 10 features which must be handled in the "SMP fashion" you'll
need 1024 kernel configuration; if you have 20 such features -- 1048576 kernel
configurations, etc.

RD> In fact, everything but the APM stuff has nothing to
RD> do with the kernel, so can we leave this behind and let
RD> the distribution people worry about it?

See above. One SMP issue ALREADY is VERY PAINFULL for distribution creators,
few other such things and distributions will require hundreds of CD's :-((
Distribution people not god's. CD's (notable bootable CD's) has A LOT OF
limitations (also CD is "only" 650Mb in size :-) -- that's why kernel suitable
for testing and kernel suitable for distribution are very different beasts.

P.S. Remember: good, friendly distributions are essentional for Linux now when
a lot of users are not hackers. Help distribution makers to create such things.
Till this will not ruin kernel clearness, of course :-))

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