Date: Sat, 6 Dec 1997 10:46:46 +0100 (MET) From: Søren Schmidt <sos@FreeBSD.dk> To: j_mini@efn.org Cc: sos@FreeBSD.dk, j_mini@efn.org, current@freebsd.org Subject: Re: Vendor-specific processor hacks Message-ID: <199712060946.KAA04299@sos.freebsd.dk> In-Reply-To: <19971205162226.26376@micron.mini.net> from Jonathan Mini at "Dec 5, 97 04:22:26 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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 ..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712060946.KAA04299>