From owner-svn-src-head@FreeBSD.ORG Fri Sep 5 18:08:14 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95D5DC3F; Fri, 5 Sep 2014 18:08:14 +0000 (UTC) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 56BE11939; Fri, 5 Sep 2014 18:08:13 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id 90482783714; Sat, 6 Sep 2014 03:43:06 +1000 (EST) Date: Sat, 6 Sep 2014 03:43:04 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin Subject: Re: svn commit: r270850 - in head/sys: i386/i386 i386/include i386/isa x86/acpica In-Reply-To: <201409051044.05853.jhb@freebsd.org> Message-ID: <20140906033051.A1982@besplex.bde.org> References: <201408301748.s7UHmc6H059701@svn.freebsd.org> <3070015.668SIdAzOX@ralph.baldwin.cx> <20140905084305.GN2737@kib.kiev.ua> <201409051044.05853.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=BdjhjNd2 c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=6p4dWWagHjQA:10 a=gxbj2yEgeIQA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=sZ-NFdfg8zaX1CIR4RwA:9 a=CjuIK1q_8ugA:10 a=Jdm36EHaYjsA:10 a=afaCV70lbk4A:10 Cc: Konstantin Belousov , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 18:08:14 -0000 On Fri, 5 Sep 2014, John Baldwin wrote: > We might also consider removing support for 486sx CPUs and requiring an > on-CPU FPU for i386. If we do that we might able to use a common fpu.c > which would be even nicer. You mean a common npx.c. The 'x' part of npx.c is much more descriptive now than it was when the only extension was the floating point one. The 'n' part of npx.c is now too specific, but not as specific as the 'fp' part of fpu.c. Bruce