Date: Fri, 5 Dec 1997 16:22:26 -0800 From: Jonathan Mini <j_mini@efn.org> To: sos@FreeBSD.dk Cc: j_mini@efn.org, FreeBSD current <current@freebsd.org> Subject: Re: Vendor-specific processor hacks Message-ID: <19971205162226.26376@micron.mini.net> In-Reply-To: =?iso-8859-1?Q?=3C199712051159=2EMAA08216=40sos=2Efreebsd=2Edk=3E=3B_fro?= =?iso-8859-1?Q?m_S=F8ren_Schmidt_on_Fri=2C_Dec_05=2C_1997_at_12=3A59=3A1?= =?iso-8859-1?Q?0PM_%2B0100?= References: <19971205025235.38183@micron.mini.net> <199712051159.MAA08216@sos.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. 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? Do we want to go through the same debate we went over with the F00F bug about the next bug that comes along? I would hope not, and with a processor class and vendor classification method, the same issue wouldn't be an issue anymore, because the code would be able to conditionally compile out on everything but the specific type of processor which it affects. Søren Schmidt <sos@FreeBSD.dk> stands accused of saying: > In reply to Jonathan Mini who wrote: > > Søren Schmidt <sos@FreeBSD.dk> stands accused of saying: > > > > > 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. > > You surely is intelligent enough to compile with option NO_FOOF_HACK then ?? > Or whatever it is you dont want... > > > 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. > > No I'm argueing that you allready have the option of not including the > hacks, its just a matter of HOW its done, and I think the current method > covers it pretty well... > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > 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?19971205162226.26376>