Date: Tue, 18 Jun 2013 14:17:53 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Marius Strobl <marius@alchemy.franken.de> Cc: arch@freebsd.org, Niclas Zeising <zeising@freebsd.org> Subject: Re: Bus space routines Message-ID: <51C0A451.4010903@FreeBSD.org> In-Reply-To: <20130618124038.GV53058@alchemy.franken.de> References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C044DA.8030406@freebsd.org> <20130618124038.GV53058@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-18 08:40:38 -0400, Marius Strobl wrote: > 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. AFAIK, bus_space(9) can only work for amd64 and i386 in userland by pure luck. It can never work for powerpc if I'm reading the MD headers correctly. Also, I strongly disagree with abusing bus_space because it gives a bad example. Jung-uk Kim >> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRwKRRAAoJECXpabHZMqHO5nIIAIjHmaY76EkvsRtWt3UA7H37 b6ObZOQiFyEJYEA2T6ArwML0IqNjMiMbdUgEEDpuctLe7CIh8YmfWOWqWVZg07sD G0g5RqV06UnOV0FS1Agqa1PbAuG6AFsBdvqKaOIOkQhyvz3Doh4FWUzLW7qFXRqZ ok1wcs5I3nqYIHKFtUDZzMAUgOJGbLxio/ROg4/lR8FgImWvOto8Vy/++CzrRn4U pDgiqFjIq39T4bIT0EoizCTpdys64USRp7+glUJXDnGBWPCIeauI3uxSizJcHuK4 4kZlBYilq0WJ5x6Hdw4UWtrA5jgV3DcWiwFPK6ktv1MUF9YLNY4bKKJKDIeg+1M= =2ZDI -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51C0A451.4010903>