Bus space routines
Marius Strobl
marius at alchemy.franken.de
Tue Jun 18 20:32:10 UTC 2013
On Tue, Jun 18, 2013 at 08:59:00PM +0300, Konstantin Belousov wrote:
> On Tue, Jun 18, 2013 at 05:45:11PM +0200, Marius Strobl wrote:
> > 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.
> Do we ? It seems there are compat32 shims in dev/pci/pci_user.c.
>
Err, you're right, head has grown support for that some time ago and
I accidentally used a stable/9 checkout when looking at it today (MFC
after 1 week, eh :)
Still, IMO the structs for such interfaces should be laid out with
compatibility in mind and f. e. not employ u_long as it is the case
here so these shims become as simple as possible if necessary at all.
Marius
More information about the freebsd-arch
mailing list