From owner-svn-src-all@FreeBSD.ORG Wed Oct 14 16:59:28 2009 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45EC510656A3; Wed, 14 Oct 2009 16:59:28 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 2E7538FC14; Wed, 14 Oct 2009 16:59:28 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp024.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KRI00GQ0KIMYU50@asmtp024.mac.com>; Wed, 14 Oct 2009 09:59:12 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20091013.220411.-432748090.imp@bsdimp.com> Date: Wed, 14 Oct 2009 09:59:09 -0700 Message-id: References: <2E290D8D-BAF0-4E4E-A352-B00FAFD9DF83@mac.com> <20091013.180620.-1542634329.imp@bsdimp.com> <20091013.220411.-432748090.imp@bsdimp.com> To: "M. Warner Losh" X-Mailer: Apple Mail (2.1076) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r197969 - head/sys/conf X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 16:59:28 -0000 On Oct 13, 2009, at 9:04 PM, M. Warner Losh wrote: > : > Does this mean that the memory cycles on the I/O bus isn't > supported > : > for these architectures? > : > : Correct. > > Then it isn't an ISA bus. Of course it isn't an ISA bus. It's all LPC. Leaving the specialized embedded market aside, there's no point discussing real ISA busses in the FreeBSD context. Noone cares and as long as it doesn't break anything noone is going to put in effort to fix the code. > : There are no hooks to implement. If there is any FreeBSD supported > : board that actually needs to have the option ROMs scanned by orm(4), > > FreeBSD does support boards that need to have option ROMs scanned. orm(4) doesn't do anything with it. Other than claim the memory region and indirectly enforce policy, there's nothing orm(4) does. Policy should be implemented in the platform code where the knowledge exists and it should not be done as a side-effect of a driver that encodes the knowledge of a single platform by way of hardcoding numbers that don't hold on other platforms. orm(4) causes machine checks and kernel panics on PowerPC and Itanium and none of the non-i386 hardware has any real history with ISA, so the sensible thing is to have orm(4) be specific to PC hardware where it has relevance. If orm(4) is actually *required* on non-PC hardware then one only has to add the appropriate line to file.${ARCH} and it's there. -- Marcel Moolenaar xcllnt@mac.com