Date: Sat, 6 Dec 1997 05:14:26 -0500 (EST) From: cgull+usenet-881371548@smoke.marlboro.vt.us (john hood) To: Jonathan Mini <j_mini@efn.org> Cc: sos@freebsd.dk, FreeBSD current <current@FreeBSD.ORG> Subject: Re: Vendor-specific processor hacks Message-ID: <199712061014.FAA11203@smoke.marlboro.vt.us> In-Reply-To: <19971205162226.26376@micron.mini.net> References: <19971205025235.38183@micron.mini.net> <199712051159.MAA08216@sos.freebsd.dk> <19971205162226.26376@micron.mini.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712061014.FAA11203>