From owner-freebsd-current Sat Dec 6 02:14:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA05813 for current-outgoing; Sat, 6 Dec 1997 02:14:40 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smoke.marlboro.vt.us (smoke.marlboro.vt.us [198.206.215.91]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA05806 for ; Sat, 6 Dec 1997 02:14:35 -0800 (PST) (envelope-from cgull@smoke.marlboro.vt.us) Received: (from cgull@localhost) by smoke.marlboro.vt.us (8.8.7/8.8.7/cgull) id FAA11203; Sat, 6 Dec 1997 05:14:26 -0500 (EST) Date: Sat, 6 Dec 1997 05:14:26 -0500 (EST) Message-Id: <199712061014.FAA11203@smoke.marlboro.vt.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: cgull+usenet-881371548@smoke.marlboro.vt.us (john hood) To: Jonathan Mini Cc: sos@freebsd.dk, FreeBSD current Subject: Re: Vendor-specific processor hacks In-Reply-To: <19971205162226.26376@micron.mini.net> References: <19971205025235.38183@micron.mini.net> <199712051159.MAA08216@sos.freebsd.dk> <19971205162226.26376@micron.mini.net> X-Mailer: VM 6.31 under Emacs 19.34.2 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jonathan Mini writes: [a horribly formatted message-- please don't use such long lines] > My point is that creating a cpu vendor target as well as a cpu > class target will make a general enough method of determing the the > types or processor hacks to include, whithout requiring the user to > keep track of all of those processor specific hacks, and to know > which ones affect what processors. > You are saying that this is rediculous, and that tracking bugs on > a bug-by-bug basis is Good Enough. If the bug fixes are all included, nobody needs to track them. Earlier, I wrote a long response, and tossed it, but you provoked me again... :) In short, I think things would be better served by trimming down the number of options and #ifdefs. The memory saving is small, the performance impact near nil, and the user and programmer confusion factor significant. I'm not even sure that "I[3456]86_CPU" is desirable. > 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 is the debate in short. Considering that you and have are > still certain that we are right and the other guy is wrong, we > probably go on about this for dozens of messages. I'm hoping we > won't. However, I am also hoping that you will look to the future > on this issue, to the point where there are dozens of these > vendor-specific bug fixes, and probably a dozen or so cpu classes. > Everyone knows their processor's vendor and class, even the > stupider users. > Also, even though (replortedly) the current Pentium F00F bugfix > doesn't have a large perofrmance hit on the system, who's to say > that others won't? 1) If there's a large performance hit on a "bug fix", it's arguably the hardware vendor's problem, not ours. 2) It seems to me that this is a problem best handled when it arises-- who knows what the next bug is going to be, how it will affect things? We sure can't predict our *own* bugs, let alone what the hardware folks bake up (literally) for us. :) > Do we want to go through the same debate we went > over with the F00F bug about the next bug that comes along? I I assume I missed something here-- I didn't see any debate :) --jh -- Mr. Belliveau said, "the difference was the wise, John Hood, cgull intelligent look on the face of the cow." He was @ *so* right. --Ofer Inbar smoke.marlboro.vt.us