From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 11 21:00:00 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12A7916A4E8 for ; Tue, 11 Jul 2006 21:00:00 +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 0DB0143D45 for ; Tue, 11 Jul 2006 20:59:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6BKuWpZ046714; Tue, 11 Jul 2006 14:56:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 11 Jul 2006 14:56:32 -0600 (MDT) Message-Id: <20060711.145632.41678446.imp@bsdimp.com> To: jhb@FreeBSD.org From: Warner Losh In-Reply-To: <200607111548.40898.jhb@freebsd.org> References: <200607111413.37238.jhb@freebsd.org> <20060711.124811.1878034486.imp@bsdimp.com> <200607111548.40898.jhb@freebsd.org> 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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 11 Jul 2006 14:56:32 -0600 (MDT) Cc: freebsd-hackers@FreeBSD.org, mag@intron.ac, matthias.andree@gmx.de, julian@elischer.org, des@des.no, delphij@delphij.net Subject: Re: kern/99979: Get Ready for Kernel Module in C++ X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 21:00:00 -0000 > It's less ugly than it used to be, esp. with the bus_read_X() stuff. There's > no separate bus_alloc_resource/bus_setup_intr for interrupts though for > example, just bus_setup_intr() equivalent. This is pretty simple though: > > /* OS X */ > IOMemoryMap *myBarMap; > void *myBar; > u_int32_t reg; > > /* BAR 0 */ > myBarMap = provider->mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress0); > myBar = myBarMap->getVirtualAddress(); > > reg = OSReadLittleInt32(myBar, FOO_REG); > reg |= BAR_FLAG; > OSWriteLittleIntew(myBar, FOO_REG, reg); > > myBar->release(); > > In FreeBSD-7 this is something like: > > struct resource *res; > int rid; > u_int32_t reg; uint32_t is the standards compliant spelling :-) > rid = PCIR_BAR(0); > res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE); The above should be shortenable to: res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, PCIR_BAR(0), RF_ACTIVE); because we don't need to have rid be a pointer. > /* XXX: Not sure about endian.. stream_read maybe? */ no. bus_read is correct, because the pci bus is little endian by definition. bus_stream_read will read/write from native endian to bus endian. > reg = bus_read_4(res, FOO_REG); > reg |= BAR_FLAG; > bus_write_4(res, FOO_REG, reg); > > bus_release_resource(dev, SYS_RES_MEMORY, rid, res); We should be able to shorten that to: bus_release_resource(dev, res); these days. > Which is very similar though there is some clutter (bus_release_resource() > should take fewer args, like just dev and res, and it would be nice to say > something like map_bar(dev, PCIR_BAR(0)) and get back a resource *). Agreed. If you have mutliple resources, you can stack them up as well. > Usually drivers come up with macros to hide the bus handles and tags which is > an indication that they were quite unsightly (thankfully that's been fixed in > 7). :) I usually do: #define RD4(sc, r) bus_read_4(sc->res, (r)) #define WR4(sc, r, v) bus_write_4(sc->res, (r), (v)) which makes usage even shorter. It also helps me hid cross-version differences... > Anyways, if you took FreeBSD-7 and cut down some of the gunk similar to OS X > you'd have something like: > > struct resource *res; > u_int32_t reg; > > res = pci_alloc_bar(dev, PCIR_BAR(0)); > > /* XXX: endian question again */ > reg = bus_read_4(res, FOO_REG); > reg |= BAR_FLAG; > bus_write_4(res, FOO_REG, reg); > > bus_release_resource(dev, res); > > Which is at least somewhat better I think. In the case where you don't care what kind of mapping you get, that would work great. It wouldn't be too hard to implement a pci_alloc_bar that does the default allocation and mapping. Changing some of the other APIs would be more difficult... > > Also, in FreeBSD, the resources are already allocated by the bus > > code. It just changes ownership to the child when the request comes > > in... > > Yes, this has been a recent improvement. Yes. We also do it in a lazy way so that if the resource is allocated or not is transparent to the driver and the system. If it could be decoded, we reserve it. Warner