From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 11:30:38 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 02DB4A78 for ; Tue, 18 Jun 2013 11:30:38 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 752C0111E for ; Tue, 18 Jun 2013 11:30:37 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id AC2A340002 for ; Tue, 18 Jun 2013 13:30:36 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 96F7D40005; Tue, 18 Jun 2013 13:30:36 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-45-105.a163.priv.bahnhof.se [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id D10ED40002; Tue, 18 Jun 2013 13:30:34 +0200 (CEST) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3bZRtL3flMz8hVn; Tue, 18 Jun 2013 13:30:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id 4pM9c5v6a6HA; Tue, 18 Jun 2013 13:30:32 +0200 (CEST) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3bZRtH6qbMz8hVm; Tue, 18 Jun 2013 13:30:31 +0200 (CEST) Received: from [IPv6:::1] (celes.daemonic.se [IPv6:2001:470:dca9:1::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 3bZRtH5v32z9Ctq; Tue, 18 Jun 2013 13:30:31 +0200 (CEST) Message-ID: <51C044DA.8030406@freebsd.org> Date: Tue, 18 Jun 2013 13:30:34 +0200 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Marius Strobl Subject: Re: Bus space routines References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> In-Reply-To: <20130618111351.GA43938@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130618-0, 2013-06-18), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: ClamAV using ClamSMTP Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 11:30:38 -0000 On 2013-06-18 13:13, Marius Strobl wrote: > On Tue, Jun 18, 2013 at 12:20:14PM +0200, Niclas Zeising wrote: >> This has been discussed before [1], but there seem to still be a lack of >> consensus, so I'll ask again. >> >> Should in*/out* macros or bus_space* functions be used in userland code? >> The background is that the port devel/libpciaccess uses these routines >> on FreeBSD. In a first incarnation it used the bus_space* routines, see >> this patch: >> >> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=591 >> >> This was later changed to use the in*/out* macros directly, with the >> motivation that the bus_space* functions is a KPI that shouldn't be used >> in userland. See following for an updated patch: >> >> http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/files/patch-src-freebsd_pci.c?rev=815 >> >> The problem is that the in*/out* macros differ between FreeBSD and >> Debian/kFreeBSD, and Debian/kFreeBSD want to switch back to use >> bus_space* again. >> >> My question is simply, which one is correct, or should libpciaccess be >> reworked in a completely different way? > > The latter; in*/out*() are somewhat okay if you want to restrict this > to work on x86 without PCI domains only. The above approach to using > bus_space(9) is one big hack, though. The right way for employing that > API is to allocate the corresponding bus resource of a particular device > and then to obtain bus tag and handle via rman_get_bus{tag,handle}(9) - > which won't work from userland, however. The shortcut to just stick in > {AMD64,I386}_BUS_SPACE_IO instead is totally unportable as generally > a bus tag isn't a mere constant and also may depend on which PCI bus > and domain a particular device is located on/in. > What we really need is a proper interface allowing userland to access > PCI I/O and memory registers, f. e. via /dev/pci, and for libpciaccess > to build upon that, i. e. essentially the same as things work on/with > Linux and /sys/bus/pci/device. As a side-effect this then also permits > to properly sanity check PCI accesses from userland within the kernel. > > Marius > That is true, however, it won't build itself today, and we need to have this working in the meantime, so what do you suggest we use for now? Also, as a side note, how hard would it be to implement this API, do you think? Is it something a junior hacker (that is, me) can do? Regards! -- Niclas