From owner-freebsd-current Fri Dec 5 03:59:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA18306 for current-outgoing; Fri, 5 Dec 1997 03:59:02 -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 DAA18295 for ; Fri, 5 Dec 1997 03:58:56 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.8.8) id MAA08216; Fri, 5 Dec 1997 12:59:10 +0100 (MET) (envelope-from sos) Message-Id: <199712051159.MAA08216@sos.freebsd.dk> Subject: Re: Vendor-specific processor hacks In-Reply-To: <19971205025235.38183@micron.mini.net> from Jonathan Mini at "Dec 5, 97 02:52:35 am" To: j_mini@efn.org Date: Fri, 5 Dec 1997 12:59:10 +0100 (MET) Cc: current@freebsd.org (FreeBSD current) 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: > Søren Schmidt 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 ..