From owner-freebsd-current Fri Dec 5 02:52:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA13356 for current-outgoing; Fri, 5 Dec 1997 02:52:51 -0800 (PST) (envelope-from owner-freebsd-current) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA13348 for ; Fri, 5 Dec 1997 02:52:46 -0800 (PST) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id CAA04809; Fri, 5 Dec 1997 02:52:36 -0800 (PST) Message-ID: <19971205025235.38183@micron.mini.net> Date: Fri, 5 Dec 1997 02:52:35 -0800 From: Jonathan Mini To: sos@FreeBSD.dk Cc: j_mini@efn.org, current@FreeBSD.ORG Subject: Re: Vendor-specific processor hacks Reply-To: Jonathan Mini References: <19971205003412.04149@micron.mini.net> <199712051032.LAA08003@sos.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88e In-Reply-To: =?iso-8859-1?Q?=3C199712051032=2ELAA08003=40sos=2Efreebsd=2Edk=3E=3B_fro?= =?iso-8859-1?Q?m_S=F8ren_Schmidt_on_Fri=2C_Dec_05=2C_1997_at_11=3A32=3A5?= =?iso-8859-1?Q?7AM_+0100?= X-files: The Truth is Out There Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Søren Schmidt stands accused of saying: > 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 am not talking about perormance boost code specifically, nor peformance tuning, but rather bug hacks and any similar things which are required for security reasons. (or whatever) The "enabled by default" options need to be easily disableable in groups, and the easiest and most extendable way to do that is to break them in to processor classification. We have half of the classification already : the processor class, but we don't have the the other half, which is chip vendor. > I know this leads to a certain amount of bloat for some processors, but > thats "just too bad".. This is my point : why should they bloat the other family's unnecissarily? In most situations, the options will be left in the kernel, so the code will be the same as it is now, but for those of us users who are intelligent enough ot know that what kind of processor we have, it would be better to not punish us. > 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... Yes and no. It still is present, and it still does cause some execution, even if it is only a few if statements in trap.c. My point is that this shouldn't happen. (whether or not this is an issue is not my point. My point is that we need to classify these types of hacks in an extendable matter. I am looking 'to the future' here, not at an an immediate Intel-oops) > 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.... Your point of all processors being equal because they all cause bloat is not the issue here. I am not aruging that Intel is special, I am arguing that Intel code is bloating a Cyrix or an Amd system. If Amd code were bloating an Intel system, I would be just as annoyed. > > 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 > .. -- 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."