From owner-svn-src-head@FreeBSD.ORG Wed Oct 14 17:44:46 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3924A106566C; Wed, 14 Oct 2009 17:44:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D1A4F8FC23; Wed, 14 Oct 2009 17:44:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n9EHdjgT026068; Wed, 14 Oct 2009 11:39:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 14 Oct 2009 11:39:45 -0600 (MDT) Message-Id: <20091014.113945.74724941.imp@bsdimp.com> To: xcllnt@mac.com From: Warner Losh In-Reply-To: References: <20091013.220411.-432748090.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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-head@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 14 Oct 2009 17:44:46 -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. LPC is a real ISA bus in this context, since it passes the memory range decodes. Your changes to break things. It is a kludge. I can't be more clear than this. You keep ignoring me, and it is very frustrating. > > : 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. Please listen. orm(4) isn't the problem. The problem is that the powerpc and itanium isa modules allow memory ranges that shouldn't be allowed. That's the platform specific code that needs to be fixed. > 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. To be pedantic: powerpc's buggy isa MD code is causing these problems. orm(4) is just a symptom, not the disease. Warner