From owner-freebsd-current Sat Dec 6 01:46:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA04413 for current-outgoing; Sat, 6 Dec 1997 01:46:24 -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 BAA04406 for ; Sat, 6 Dec 1997 01:46:12 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.8.8) id KAA04299; Sat, 6 Dec 1997 10:46:52 +0100 (MET) (envelope-from sos) Message-Id: <199712060946.KAA04299@sos.freebsd.dk> Subject: Re: Vendor-specific processor hacks In-Reply-To: <19971205162226.26376@micron.mini.net> from Jonathan Mini at "Dec 5, 97 04:22:26 pm" To: j_mini@efn.org Date: Sat, 6 Dec 1997 10:46:46 +0100 (MET) Cc: sos@FreeBSD.dk, j_mini@efn.org, 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 feel like creating a long thread where we both keep saying 'you're > wrong, no you're wrong, no .. you're wrong' over and over again. hear hear! > The question is whether or not a user should be required to keep track of all > of the bugs that have popped up for their specific processor and enable those > fixes. (or disable the ones that don't affect them) > I say that this isn't very reasonable, and that the user should only be > required to keep track of his processor's make and model rather than all of the > specific mistakes that his vendor made. 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. This covers the vast majority of the users. Then for the hacker types (like you & me :) ), we can disable those CPU types, and the hacks we dont like. This is exaclty what the current model buys us. 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'm sorry, but that is still my viewpoint, I see your arguments, but for the next couple of releases (years) what we have will do nicely... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end ..