Date: Tue, 18 Jun 2013 14:50:33 +0200 From: Niclas Zeising <zeising@freebsd.org> To: Marius Strobl <marius@alchemy.franken.de> Cc: arch@freebsd.org Subject: Re: Bus space routines Message-ID: <51C05799.30304@freebsd.org> In-Reply-To: <20130618124038.GV53058@alchemy.franken.de> References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C044DA.8030406@freebsd.org> <20130618124038.GV53058@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013-06-18 14:40, 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. Ok. I'll see if someone else chimes in on this, otherwise we'll switch back to bus_space(9) 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? > > Well, I'd say that technically this shouldn't be hard to do but mainly > a question of having the time to implement and test it. In other words, > IMO this would make a rather good GSOC project or generally a great > opportunity to get ones feet wet in kernel and API land. Probably, the > main issue here is that - from looking at the libpciaccess sources - > none of the supported OS currently provides such an interface that is > really sound and, thus, may serve as a viable reference. The Linux > sysfs method at least should illustrate what is required from a > functionality point of view, though. I'll have a look at this, as you said, it might be a good way to get my feet wet and see of stuff works. I can always throw it out if I fail, and ask around on mailing lists for guidance and help. Regards! -- Niclas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51C05799.30304>