From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 20:32:10 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0C471A16; Tue, 18 Jun 2013 20:32:10 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 821E0120A; Tue, 18 Jun 2013 20:32:09 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.6/8.14.6/ALCHEMY.FRANKEN.DE) with ESMTP id r5IKW2FV018765; Tue, 18 Jun 2013 22:32:02 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.6/8.14.6/Submit) id r5IKW2Vt018764; Tue, 18 Jun 2013 22:32:02 +0200 (CEST) (envelope-from marius) Date: Tue, 18 Jun 2013 22:32:02 +0200 From: Marius Strobl To: Konstantin Belousov Subject: Re: Bus space routines Message-ID: <20130618203202.GZ53058@alchemy.franken.de> References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C07A2F.3060504@FreeBSD.org> <20130618154511.GY53058@alchemy.franken.de> <20130618175900.GY91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130618175900.GY91021@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@FreeBSD.org, Andriy Gapon , Niclas Zeising X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:32:10 -0000 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