From owner-svn-src-all@FreeBSD.ORG Wed Oct 14 18:35:18 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 D9A50106566C; Wed, 14 Oct 2009 18:35:18 +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 C30218FC18; Wed, 14 Oct 2009 18:35:18 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Received: from [172.24.241.207] (natint3.juniper.net [66.129.224.36]) by asmtp024.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KRI00N49OYS1O30@asmtp024.mac.com>; Wed, 14 Oct 2009 11:35:18 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20091014.113945.74724941.imp@bsdimp.com> Date: Wed, 14 Oct 2009 11:35:16 -0700 Message-id: <2D55EFED-675A-4CC7-AF39-DE83961552F0@mac.com> References: <20091013.220411.-432748090.imp@bsdimp.com> <20091014.113945.74724941.imp@bsdimp.com> To: 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 18:35:18 -0000 On Oct 14, 2009, at 10:39 AM, Warner Losh wrote: > > I can't be more clear than this. You keep ignoring me, and it is very > frustrating. I'm not ignoring you. I'm still talking. You simply haven't convinced me. While it's possible (likely?) that I don't understand the issues, all you've achieved so far is that I'm more convinced that limiting orm(4) to i386 and amd64 is the right thing, because the alternative is not at all appealing. > 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. isa_set_resource() is MI code and it happily adds whatever resources a driver wants. The only chance MD code has is to fail the allocation, but since the whole ISA code bypasses the newbus hierarchy, there's no way we know in the isa MD code what is valid and what isn't unless we add kluges to platform code. If you want to fix it for real, does that mean fix it for real or does that mean add kluges to platform code? Shouldn't we have ISA bridges obtain the set of valid resources from their parent in the newbus hierarchy? > To be pedantic: powerpc's buggy isa MD code is causing these > problems. orm(4) is just a symptom, not the disease. Fine, be pedantic. I eliminated the symptom. Good, now at least I'm not blocked and we can really discuss the disease and fix it. See above. -- Marcel Moolenaar xcllnt@mac.com