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