Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Jun 2013 13:13:51 +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:  <20130618111351.GA43938@alchemy.franken.de>
In-Reply-To: <51C0345E.4000309@freebsd.org>
References:  <51C0345E.4000309@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130618111351.GA43938>