From owner-freebsd-current Fri Dec 6 20:47:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA28749 for current-outgoing; Fri, 6 Dec 1996 20:47:08 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA28743 for ; Fri, 6 Dec 1996 20:47:05 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id XAA00297; Fri, 6 Dec 1996 23:45:33 -0500 (EST) From: "John S. Dyson" Message-Id: <199612070445.XAA00297@dyson.iquest.net> Subject: Re: 3.0-current Kernel panicking on bootup To: bde@zeta.org.au (Bruce Evans) Date: Fri, 6 Dec 1996 23:45:33 -0500 (EST) Cc: bde@zeta.org.au, current@freebsd.org, dyson@dyson.iquest.net, markm@iafrica.com In-Reply-To: <199612070419.PAA14363@godzilla.zeta.org.au> from "Bruce Evans" at Dec 7, 96 03:19:40 pm Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > This means that if you make it conditional on the various processors that > support it, then you break GENERIC on i386's. GENERIC is configured to > support all processors. If you remove the support for i486's and up from > it then people who run GENERIC will get all the disadvantages of the i386, > e.g., no CR0_WP. > Right, so what I just committed will support the bswap insn on systems that support any of (486,586,686) and don't support the 386. LKM's will be built with the default support of the 386. It doesn't break 686 machines, but it is slower to use LKM based code. We can improve the code in the 386 case by changing the inlines as you suggest. It appears to me to be terrible not to use the nicely provided bswap instruction that runs in 1 cycle. In the case of the other code in the system (incl VM system), we are stuck with the earlier processors' legacy. When it is a good idea, we can come up with unique solutions for each type of backwards compatibility need. If there is an efficient general way of doing things, I cannot think of it... John