From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 21:15:06 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by hub.freebsd.org (Postfix) with ESMTP id F341B6D3; Tue, 18 Jun 2013 21:15:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <51C0CDBE.40501@FreeBSD.org> Date: Tue, 18 Jun 2013 17:14:38 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130517 Thunderbird/17.0.6 MIME-Version: 1.0 To: Marius Strobl Subject: Re: Bus space routines References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C044DA.8030406@freebsd.org> <20130618124038.GV53058@alchemy.franken.de> <51C0A451.4010903@FreeBSD.org> <20130618205943.GA53058@alchemy.franken.de> <51C0CBE8.5030904@FreeBSD.org> In-Reply-To: <51C0CBE8.5030904@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Robert Millan , Niclas Zeising 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 21:15:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-18 17:06:48 -0400, Jung-uk Kim wrote: 2013? 6? 18? 17:06, Jung-uk Kim ? ?:> On 2013-06-18 16:59:43 - -0400, Marius Strobl wrote: >> On Tue, Jun 18, 2013 at 02:17:53PM -0400, Jung-uk Kim wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 2013-06-18 08:40:38 -0400, Marius Strobl wrote: >>>> On Tue, Jun 18, 2013 at 01:30:34PM +0200, Niclas Zeising >>>> wrote: >>>>> 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. >>>>>> >>>>> >>>>> 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? >>>> >>>> That's hard to say as architecturally neither in*/out*() nor >>>> bus_space(9) are the way to proceed. Tentatively, I'd go >>>> with abusing the latter as that approach _should_ allow to >>>> make things additionally work one another one or two >>>> architectures - in particular powerpc - without introducing >>>> an #ifdef hell. >>> >>> AFAIK, bus_space(9) can only work for amd64 and i386 in >>> userland by pure luck. It can never work for powerpc if I'm >>> reading the MD headers correctly. > >> Actually, I think that by cloning bs_le_tag in userland as far as >> necessary, i. e. leaving out things like mapping/unmapping and >> allocation/deallocation etc., and using that as bus tag, >> bus_space(9) has a fairly good chance of working in userland for >> powerpc in this case. Obviously, that's harder to do than faking >> the bus tag for x86, though. > > Please don't forget the point of this thread, i.e., finding simple > MI interface. ;-) > >>> Also, I strongly disagree with abusing bus_space because it >>> gives a bad example. > >> Well, I strongly believe that both in*/out*() and bus_space(9) >> give very bad examples for userland code :) > > If you insist, we can simply use io(4). I went ahead and implemented it: http://people.freebsd.org/~jkim/libpciaccess.diff This should work with powerpc and other platforms with working io(4). Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRwM2+AAoJECXpabHZMqHOE48H/R1+E2H9Kww/b9STnLKih9po eD5HrRB+iQCe3qjzh328ulyvraBiCIyIf0irUMJ7H0e6k/bPQaepAcE6DURrnG1x IrB+Nntx5o+NOeq96kEaIQhD48beZfKcHao81y0+YEzYK9taE+JAOFTmGVACZFXd 2/ZqCB3wyD9gSN1WbUZQ+BNGWn4geUNDvkXgOiyov70AidaL5lkrXNuQSCAp9Mwl X1uclYYDLl9nPXtx9m/l8bxLNryL6p7ONzDRASpHhjoRiVNiYttOSnIDzJwC8mWn 3BEaqJraNjdzhpme1vV78e82/g88CWZN2NHicXqnHnAopU+Pc4RRev301Mf8zjU= =ORB9 -----END PGP SIGNATURE-----