> linux kernel account wrote:
> >
> ...
> >
> > Lets then remove ALL cpu detection from the kernel.. If you do something
> > then do it right and completely.. Or dont do it at all.
>
> Sorry, but aren't you being slightly radical?
actually - probably assume a *grin* in that statment... and believe it or
not your stance is more radical....
> As I stated before, doing it "right and completely" in this case (i386
> kernel CPU detection) means the kernel should be able to boot and
> correctly execute on all i386 compatible processors; without any strange
> oops.
1. There's no such thing as a proper 386 detection routine.
2. Same applies to 486 (and relatives - 5x86, K5, ...)
3. Same applies to early pentiums (and relatives - eg 6x86)
and finally:
4. Every processor must have a proper speed approximation or things may
Blow Up(tm:).... And every processor travels at a different speed...
... and handles instructions at different speeds...
(if you want nightmares read timing for cyrix 386...)
[at least pentium-II documents how it adjusts instruction speeds..]
2nd-generation pentiums, K6's, prolly newer 6x86's and newer chips don't
have these headaches (they add new ones - but that's another story);
The moral?
There Ain't No Such Thing As A Free Lunch
The code has to be there. It's not big or particularly space consuming, so
what's the problem?
We are not Microsoft who declares that one and only one chip is well
supported...
> On the other hand, if you want to write a good user-space utility to
> detect and configure i386 compatible processors for maximum performance,
> a good GPLed code basis would be set6x86. Koen Gadeyne has signaled that
> he is not against somebody improving on his code. And you can add as
> many features as you can think of without ever having anybody complain
> about bloated code.
I would like to point out that as there are processor-specific features
(eg. locked cache lines in 6x86) that could optimize system speed
logarithmically.... or slow it down such... some features should only be
present in kernel-space.
The same goes for processor-specific repair (such as catching the "Pentium
Death" combos...)
> I prefer to have the Linux kernel source as clean and trim as possible.
I would prefer that it works. Working efficiently is even better. If the
price of conformity is efficiency, I'll happily sacrifice conformity!
One last comment :
Linux exists on other platforms and contains code specific to
those platforms in order to operate. Are you going to ask for this to be
removed to cut down on code bloat? [hint: such a move would be very bad...]
This issue is not sizeably different ... enough of this. Just include the
code please? :)
G'day, eh?...
- Teunis