Re: Cyrix patch : Proposal?
Willem Riede (wriede@monmouth.com)
Sat, 08 Nov 1997 10:32:34 -0500
On Fri, 7 Nov 1997, Andre Derrick Balsa <andrewbalsa@usa.net> wrote:
> Hi Nigel,
>
> Nigel Metheringham wrote:
> >
> > linker@nightshade.z.ml.org said:
> > } A very good post. I would assume that you approve of minor patching so
> > } that cpuinfo displays the correct information?
> >
> > If this was done then userlevel tools could twiddle happily knowing that
> > they had the right CPU to play with.
>
> This is correct, but it's not a good enough reason to implement a patch:
> it's much easier to write a good user-level utility that will correctly
> detect the CPU type, revision, speed, etc... than to put all of this in
> the kernel.
>
> IMHO there are 2 valid reasons for kernel patching when it comes to
> Cyrix CPUs:
>
> 1) If the kernel will either not boot at all, or will boot but setup its
> working parameters incorrectly (e.g. wrong bogomips/udelay settings may
> cause problems with some drivers that use udelay for timing loops). This
> was a point I discussed at length with Pavel Machek.
>
You may have discussed it, but you have not convinced me. I still have a fundamental problem with the position you've taken.
Even if some (or most) options can be set from user space, I want the kernel to take care of recognizing the chip and setting all safe options to take advantage of them.
I think it would be a feather in Linux's cap if it automatically recognized
what CPU it runs on and sets any parameters that make that CPU function most
effectively (and some may have to be set at config for recompile time).
I think this is more important than keeping "the Linux kernel source as clean and trim as possible" as you put it in another posting, and not likely to result in significant "bloat".
I don't expect to convince you, but I don't think one opinion should be allowed to dominate.
Regards, Willem Riede.