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>