Date: Tue, 18 Jun 2013 17:45:11 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Andriy Gapon <avg@FreeBSD.org> Cc: arch@FreeBSD.org, Niclas Zeising <zeising@FreeBSD.org> Subject: Re: Bus space routines Message-ID: <20130618154511.GY53058@alchemy.franken.de> In-Reply-To: <51C07A2F.3060504@FreeBSD.org> References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C07A2F.3060504@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 18, 2013 at 06:18:07PM +0300, Andriy Gapon wrote: > on 18/06/2013 14:13 Marius Strobl said the following: > > 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. > > We have this pciconf utility (in base), which can read PCI config registers (and > more). Apparently it uses some ioctl interface of /dev/pci. > Is this the interface that you had in mind or does it lack some required capabilities? > Currently, that pci(4) userland interface is limited to configuration space only (and libpciaccess indeed already makes use of it for that purpose). What Xorg now additionally requires from such an interface is access to I/O and/or (haven't looked at it in that detail so far) memory registers of PCI devices. Extending /dev/pci to also provide this, thus, certainly is one proper way to go. As a side-note, unfortunately, at least struct pci_conf and pci_match_conf aren't particularly well-thought when it comes to implementing backwards compatibility to previous versions of that interface etc. What we still lack f. e. is support for 32-bit applications using that API on a 64-bit kernel. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130618154511.GY53058>