Date: Fri, 5 Dec 1997 11:32:57 +0100 (MET) From: Søren Schmidt <sos@FreeBSD.dk> To: j_mini@efn.org Cc: current@FreeBSD.ORG Subject: Re: Vendor-specific processor hacks Message-ID: <199712051032.LAA08003@sos.freebsd.dk> In-Reply-To: <19971205003412.04149@micron.mini.net> from Jonathan Mini at "Dec 5, 97 00:34:12 am"
next in thread | previous in thread | raw e-mail | index | archive | help
In reply to Jonathan Mini who wrote:
I don't agree on that, because:
Joe Random user should get all the fixes etc that is RELIABILITY related
just out of the box. Certain speedups for specific CPU's can be held
as option BLA_BLA, as they are not mission critical to a stock system.
I know this leads to a certain amount of bloat for some processors, but
thats "just too bad"..
The way this is now, the FOOF hack is present in kernels with I586_CPU
defined, but only enabled on genuine Intel cpu's, exactly as should be...
I am sure that if one of the other cpu's have faults (which I'm certain
they have :) ), and it makes the system unusable/unsecure/unstable, that
code will be integrated too, and will be bloat on the other families
as well... Intel is not special here, nor are the others....
> In light of the current F00F bug, and other vendor-specific hacks, such as
> the performance tuning for the Curix chipsets and Intel's floating-point bug,
> and other items of that issue, I would like to propose adding a set of options
> to define the vendor target range of the kernel.
> This would, in effect, allow for an easy method of conditionally compiling
> vendor-specific hacks. For example, the F00F hack would be wrapping in an
> #ifdef defined(I586_CPU) && (CPU_INTEL) && !defined(CPU_NO_F00F_HACK) /* ... */
> #endif pair, and in the kernel you'd see :
>
> options CPU_INTEL #Enable Intel Quirks
>
> A CPU_vendor tag would be a very clean and easy way to manage these
> vendor-specific hacks, and it allows us to easily integrate new vendor bugfixes
> without affecting the people who don't have a processor from that vendor. (For
> example, all of my FreBSD boxes except for my crash machine are AMD chipsets,
> and I am soon going to be upgrading that machine to an AMD processor. The Intel
> F00F bug never affected me, and it never should. Beleive it or not, Club Intel
> folks, there are a lot more AMD machines out there than you think. :))
> On the other hand, on the hypothetical event that an AMD processor bug ever
> appears, I would like to rest assured that a simple cvsup and recompile with my
> current config (with a CPU_AMD defined) would have the latest AMD bugfixes.
>
> --
> Jonathan Mini Ingenious Productions
> Software Development P.O. Box 5693,
> Eugene, Or. 97405
>
> "A child of five could understand this! Quick -- Fetch me a child of five."
>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team
Even more code to hack -- will it ever end
..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712051032.LAA08003>