Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 Dec 1997 02:52:35 -0800
From:      Jonathan Mini <j_mini@efn.org>
To:        sos@FreeBSD.dk
Cc:        j_mini@efn.org, current@FreeBSD.ORG
Subject:   Re: Vendor-specific processor hacks
Message-ID:  <19971205025235.38183@micron.mini.net>
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_%2B0100?=
References:  <19971205003412.04149@micron.mini.net> <199712051032.LAA08003@sos.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
Søren Schmidt <sos@FreeBSD.dk> 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."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971205025235.38183>