From owner-freebsd-new-bus@FreeBSD.ORG Mon Oct 2 21:09:18 2006 Return-Path: X-Original-To: freebsd-new-bus@freebsd.org Delivered-To: freebsd-new-bus@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAAF616A403 for ; Mon, 2 Oct 2006 21:09:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47F1A43D46 for ; Mon, 2 Oct 2006 21:09:18 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k92L94sc080475; Mon, 2 Oct 2006 15:09:04 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 02 Oct 2006 15:08:12 -0600 (MDT) Message-Id: <20061002.150812.151470856.imp@bsdimp.com> To: john@baldwin.cx From: "M. Warner Losh" In-Reply-To: <200610021620.44185.john@baldwin.cx> References: <200610021403.50339.john@baldwin.cx> <20061002.134204.-749250271.imp@bsdimp.com> <200610021620.44185.john@baldwin.cx> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 02 Oct 2006 15:09:05 -0600 (MDT) Cc: freebsd-new-bus@freebsd.org Subject: Re: Properly managing sub-allocations X-BeenThere: freebsd-new-bus@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD's new-bus architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2006 21:09:18 -0000 In message: <200610021620.44185.john@baldwin.cx> John Baldwin writes: : On Monday 02 October 2006 15:42, M. Warner Losh wrote: : > In message: <200610021403.50339.john@baldwin.cx> : > John Baldwin writes: : > : > However, this may break some existing drivers that allocate a BAR, : > : > peek at its type and then either activate it or allocate another : > : > BAR... The TAG is valid, but the handle isn't. : > : : > : They generally peak at the BAR register itself though, not the value of : > : rman_get_bustag() though, right? : > : > Some do, some get the resource and look at it. There's a lot of : > variance here. Do you put knowledge of how to decode PCI bars into : > every driver, or do you let the pci bus take care of it? Since the : > knowledge is nearly trivial, different people decide differenly. It : > is still a technique that has been used, and you'll need to be careful : > to make sure you don't break anything. After all, 0 is a valid I/O : > tag and it is also the default value... : : Err, how can code examine the actual bus tag value of a non-active resource? : By definition it's set an opaque MD value. You can't compare it against : SYS_RES_MEMORY for example. On i386 systems it happens to be an int, on some : other systems (alpha maybe?) I think it can be a pointer to a structure of : function pointers for the different bus space operations. I don't think any : MI code should ever be examining the bus tag or handle except to pass them as : opaque parameters to bus_space_*(). Actually, you are right. I'm confusing success/failure of allocating a I/O and/or Memory bar with this... Warner