From owner-svn-src-all@FreeBSD.ORG Thu Oct 15 06:00:01 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 6340E1065676; Thu, 15 Oct 2009 06:00:01 +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 0F93D8FC22; Thu, 15 Oct 2009 06:00:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n9F5r241034850; Wed, 14 Oct 2009 23:53:02 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 14 Oct 2009 23:53:15 -0600 (MDT) Message-Id: <20091014.235315.62961324.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <200910141738.43910.jhb@freebsd.org> <20091014.224434.-345402487.imp@bsdimp.com> X-Mailer: Mew version 5.2 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, jhb@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: Thu, 15 Oct 2009 06:00:01 -0000 In message: Marcel Moolenaar writes: : : On Oct 14, 2009, at 9:44 PM, M. Warner Losh wrote: : > This is also the source of my frustration with the thread, I think. I : > don't think that Marcel understood this world view and assumed that no : > mapping was needed and therefore orm was this horribly x86 specific : > code. Since I didn't understand this until today, I reacted badly and : > lost my temper, for which I'd like to apologize. I should have : > stopped and explained this view better. : : Apology accepted. Sorry, if I appeared frustrated as well. : : I can respect the PoV that the hardcoding in drivers are bus addresses. : I have no problem with that. It isn't my PoV, because it doesn't match : with the existence of functions like inb(), outb(), inw(), outw(), etc. inb, etc, aren't part of bus_space and exist outside of it. These functions typically don't exist on !x86 platforms, and when they do they are very platform specific.. : The I/O port numbers passed to those functions are typically absolute : due to the total lack of newbus involvement. I merely extrapolated the : memory addresses as behaving in the same way. They do actually, because : VGA frame buffer memory is at 0xA0000 and part of the PCI specification : and you don't want to translate that, so how does MD code know when to : map and when not to? It doesn't, so the only logical interpretation is : that the addresses are absolute and no mapping can be done. The PCI specification says that the frame buffer is at 0xa0000 in the pci bus space. It doesn't say anything about how that bus space is mapped into the processor's address space (although it comments on x86's traditional mapping in many places). : I don't mind changing the interpretation of I/O ports and memory : addresses as being ISA bus addresses, but that means that we need to : get rid off inb(), outb(), et al and use newbus through out. Until : that's done (and people figure out how to deal with VGA resources) or : there's a real need for orm(4), it's safest for non-PC platforms to not : have orm(4) wreck havoc. There is a real need for orm. I'm open to ways to improve the situation without requiring the complete implementation of the ISA stuff. The reason that it does wreck havoc is because there's problems in the ISA implementation on the platforms it wrecks havoc on. You can mask these problems by removing orm. However, any other isa device that reads memory will have issues on these platforms. The VGA resource issue should be a simple one to deal with via bus_spae. This is the first time I've heard of it, frankly, so would be interested in learning more about it. We've also, as a project, have strongly encouraged drivers to move away from inb, et al, and direct memory access to using bus_space interfaces since around FreeBSD 4.0. Many drivers have been converted. I think the few stragglers were killed as part of the network modernization efforts, although some pre-ISA PNP support still uses inb/outb directly. I think I'd quibble that it is !x86. It is specific to powerpc and itanium platforms. Sparc64 handles it correctly, as does arm (at east in the projects/arm tree). I don't think that mips has any ISA support, even in the projects/mips tree. Warner