From owner-freebsd-current Fri Dec 5 02:32:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA11621 for current-outgoing; Fri, 5 Dec 1997 02:32:43 -0800 (PST) (envelope-from owner-freebsd-current) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA11615 for ; Fri, 5 Dec 1997 02:32:39 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.8.8) id LAA08003; Fri, 5 Dec 1997 11:32:57 +0100 (MET) (envelope-from sos) Message-Id: <199712051032.LAA08003@sos.freebsd.dk> Subject: Re: Vendor-specific processor hacks In-Reply-To: <19971205003412.04149@micron.mini.net> from Jonathan Mini at "Dec 5, 97 00:34:12 am" To: j_mini@efn.org Date: Fri, 5 Dec 1997 11:32:57 +0100 (MET) Cc: current@FreeBSD.ORG From: Søren Schmidt Reply-to: sos@FreeBSD.dk X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 ..