Date: Tue, 18 Jun 2013 22:59:43 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Jung-uk Kim <jkim@FreeBSD.org> Cc: arch@freebsd.org, Niclas Zeising <zeising@freebsd.org> Subject: Re: Bus space routines Message-ID: <20130618205943.GA53058@alchemy.franken.de> In-Reply-To: <51C0A451.4010903@FreeBSD.org> References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C044DA.8030406@freebsd.org> <20130618124038.GV53058@alchemy.franken.de> <51C0A451.4010903@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > 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 :) Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130618205943.GA53058>