From owner-freebsd-current Sat Dec 6 04:45:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA15145 for current-outgoing; Sat, 6 Dec 1997 04:45:23 -0800 (PST) (envelope-from owner-freebsd-current) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA15135 for ; Sat, 6 Dec 1997 04:45:09 -0800 (PST) (envelope-from rkw@dataplex.net) Received: from [208.2.87.4] (user4.dataplex.net [208.2.87.4]) by shrimp.dataplex.net (8.8.5/8.8.5) with ESMTP id GAA07263; Sat, 6 Dec 1997 06:44:59 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199712060946.KAA04299@sos.freebsd.dk> References: <19971205162226.26376@micron.mini.net> from Jonathan Mini at "Dec 5, 97 04:22:26 pm" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 6 Dec 1997 06:39:40 -0600 To: sos@FreeBSD.dk From: Richard Wackerbarth Subject: Re: Vendor-specific processor hacks Cc: current@FreeBSD.ORG Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id EAA15137 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 3:46 AM -0600 12/6/97, S¯ren Schmidt wrote: >That's exactly the point, and my standpoint is still that all hacks for a >given CPU type (I?86_CPU) should be compiled in if one does nothing to >prevent it. I agree. The default case should be "all the workarounds are included" >I dont like another bazillion #ifdefs and stuff just to make a few >hackers happy, they are knowledgeable enough (or should be) to >do this by themselves. I think a problem is in the naming of the #ifdef's. Right now, things tend to be messy where the tests for "this, that, and the other, but not something else" have made their way into the code itself. This is caused by a failure to abstract things. The fixes should each have their own label. The label should represent the problem, not the machine that has the problem. Then, in addition, we should supply a header file that defines the cpu -> fault matrix. Why shouldn't we "do it once" rather than expect everyone to reinvent the same wheel? The only complication that I see is that we tend to think in the "HAS_BUG" mode rather than the "DOESNT_NEED_WORKAROUND" mode implied in the first paragraph. My proposed attack on this would be to have a hiearchy of filters which go from the specific to the general. make -DCOMPILE_FOR_INTEL_P5_90 - - - #ifdef COMPILE_FOR_INTEL_P5_90 #define CPU_IS_INTEL TRUE #define CPU_IS_586 TRUE #define MAY_HAVE_COOTIES TRUE #endif - - - #ifndef CPU_IS_INTEL #ifndef MAY_HAVE_FOOF_BUG #define MAY_HAVE_FOOF_BUG FALSE #endif #endif - - - and finally, in the code #ifndef MAY_HAVE_COOTIES #define MAY_HAVE_COOTIES TRUE #endif ... #if MAY_HAVE_COOTIES code to work around cooties #endif Richard Wackerbarth