Date: Tue, 18 Jun 2013 17:06:48 -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: <51C0CBE8.5030904@FreeBSD.org> In-Reply-To: <20130618205943.GA53058@alchemy.franken.de> References: <51C0345E.4000309@freebsd.org> <20130618111351.GA43938@alchemy.franken.de> <51C044DA.8030406@freebsd.org> <20130618124038.GV53058@alchemy.franken.de> <51C0A451.4010903@FreeBSD.org> <20130618205943.GA53058@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 16:59:43 -0400, Marius Strobl wrote: > On Tue, Jun 18, 2013 at 02:17:53PM -0400, Jung-uk Kim wrote: >> -----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. > > Actually, I think that by cloning bs_le_tag in userland as far as > necessary, i. e. leaving out things like mapping/unmapping and > allocation/deallocation etc., and using that as bus tag, > bus_space(9) has a fairly good chance of working in userland for > powerpc in this case. Obviously, that's harder to do than faking > the bus tag for x86, though. Please don't forget the point of this thread, i.e., finding simple MI interface. ;-) >> Also, I strongly disagree with abusing bus_space because it gives >> a bad example. > > Well, I strongly believe that both in*/out*() and bus_space(9) > give very bad examples for userland code :) If you insist, we can simply use io(4). Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRwMvoAAoJECXpabHZMqHOPyYIAL0KU/nKFtrSGSQvRAHN+oK1 3LqZL6sLTXwQgxc3DXKwoB9X/qBSvBSpxuJ0A2kiV0Kj2GBj67jepJFEXvg0jLSg Cscd6amKuH3JUwfd/Nz2BwEnGUk1WxZuJg68nKhLd2ahJA6aeIPDf3kGabw1lfEa Ef72lSA35eHjzpzEMPYFHO5gXy0y7IEWuqpeU4Ah+8AKKxC2TqKcvTysaadbwSFQ HctLchUih+cyDnmSq+Km8bjOy3Lv0IM6pGGwSRr1BuQ2LYug7zdIcBBviqKYZBJZ f5+i81ibU0K2TSfBTRwJhIi587nasyU7xIBjIADSx5mthi61bspAYIOFUp9HzfE= =ArO1 -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51C0CBE8.5030904>