From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 22:19:21 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 01B7CAAD for ; Tue, 18 Jun 2013 22:19:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id C4B9817FE for ; Tue, 18 Jun 2013 22:19:20 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id ar20so10963320iec.7 for ; Tue, 18 Jun 2013 15:19:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=+JXlQWe66vGa/74RAT/HI4T0elazTOkg6rFdlULp9Og=; b=KFI+PA06/ySMCp+4jw8vCamEdAqAsdOIM0QiSpLXkN9DcrT4I8crlGYyYsGgnVg6cl ahNh6hBtlGCulNXC+aIoxg0SD/QL6iSjFt2d3EQcUA+NaRMaJC0NAisnMLolh1f8rjnE JO140FJLlcFuNGd5tG09qgEJz7xSTGll1u892nw8lv3uFSeTPEgvzu+anWf81NnTnwdY dmMT5UUUW5joFts2BYuksyKgW0ZOB9hmsU6+Ew6E8iMuwWj3vnRF2/FqA6Mvo5pY1Igf 8EAuTbAUDAyOTZv2IP9X4PJB75FosBH6BIouXrkzCZ9ol/H8AJ6qY+3ROUPTNSffZlUG UA8w== X-Received: by 10.50.7.1 with SMTP id f1mr2242894iga.48.1371593960430; Tue, 18 Jun 2013 15:19:20 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id wn10sm3097262igb.2.2013.06.18.15.19.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 15:19:19 -0700 (PDT) Sender: Warner Losh Subject: Re: Bus space routines Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <51C0D92D.70608@FreeBSD.org> Date: Tue, 18 Jun 2013 16:19:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <51C0CBE8.5030904@FreeBSD.org> <51C0CDBE.40501@FreeBSD.org> <51C0CFE7.6010906@niksun.com> <20130618214957.GB53058@alchemy.franken.de> <51C0D92D.70608@FreeBSD.org> To: Jung-uk Kim X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnNlCXh5wYakmXHeMz7uaDDT+DtjTMq/WdYy9z9HvDCo+aCiNWd1MvNuwj0OGXFvviDdPHs Cc: "arch@freebsd.org" , Robert Millan , Niclas Zeising , Marius Strobl 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 22:19:21 -0000 On Jun 18, 2013, at 4:03 PM, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 2013-06-18 17:49:57 -0400, Marius Strobl wrote: >> On Tue, Jun 18, 2013 at 09:24:19PM +0000, Jung-uk Kim wrote: >>> On 2013-06-18 17:14:38 -0400, Jung-uk Kim wrote: >>>> On 2013-06-18 17:06:48 -0400, Jung-uk Kim wrote: 2013? 6? 18? >>>> 17:06, Jung-uk Kim ? ?:> 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 >>>>>>>=20 >>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> 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: >>>>>>>>>>>=20 >>>>>>>>>>> = http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/file= s/patch-src-freebsd_pci.c?rev=3D591 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>=20 >>>>=20 >>>>>>>>>>>=20 >>>>=20 >>>>>>>>>>>=20 > 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: >>>>>>>>>>>=20 >>>>>>>>>>> = http://trillian.chruetertee.ch/ports/browser/trunk/devel/libpciaccess/file= s/patch-src-freebsd_pci.c?rev=3D815 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>=20 >>>>>>>>>>>=20 >>>>=20 >>>>>>>>>>>=20 >>>>=20 >>>>>>>>>>>=20 > 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. >>>>>>>>>>>=20 >>>>>>>>>>> My question is simply, which one is correct, or >>>>>>>>>>> should libpciaccess be reworked in a completely >>>>>>>>>>> different way? >>>>>>>>>>=20 >>>>>>>>>> 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=20 >>>>>>>>>> rman_get_bus{tag,handle}(9) - which won't work from >>>>>>>>>> userland, however. The shortcut to just stick in=20 >>>>>>>>>> {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=20 >>>>>>>>>> side-effect this then also permits to properly >>>>>>>>>> sanity check PCI accesses from userland within the >>>>>>>>>> kernel. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 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? >>>>>>>>=20 >>>>>>>> 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. >>>>>>>=20 >>>>>>> AFAIK, bus_space(9) can only work for amd64 and i386 in=20 >>>>>>> userland by pure luck. It can never work for powerpc if >>>>>>> I'm reading the MD headers correctly. >>>>=20 >>>>>> 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. >>>>=20 >>>>> Please don't forget the point of this thread, i.e., finding >>>>> simple MI interface. ;-) >>>>=20 >>>>>>> Also, I strongly disagree with abusing bus_space because >>>>>>> it gives a bad example. >>>>=20 >>>>>> Well, I strongly believe that both in*/out*() and >>>>>> bus_space(9) give very bad examples for userland code :) >>>>=20 >>>>> If you insist, we can simply use io(4). >>>>=20 >>>> I went ahead and implemented it: >>>>=20 >>>> http://people.freebsd.org/~jkim/libpciaccess.diff >>>>=20 >>>> This should work with powerpc and other platforms with working >>>> io(4). >>>=20 >>> I just realized powerpc does not have /dev/io, sorry. Anyway, >>> my point was there is userland API already and we don't have to >>> reinvent the wheel. >>>=20 >>=20 >> Essentially, the issue with io(4) is the same as with in*/out*();=20 >> you can't implement it in a sane way on architectures such as >> powerpc that have busses of different endianesses, apart from some >> other complications. >=20 > Why can't we implement it to always get/set in host byte order > regardless of underlying bus? Can't the MD portion of the driver > figure it out magically? Not typically. Since all the world is intel, all the world is little = endian... Plus, the PCI bus is defined to be little endian, not host = endian. Not all drivers cope well with this. Warner >> IMO, we'll run in circles forever without a new userland interface >> or without extending an existing one to be able to deal with all >> these MD requirements (as such, thinking in the direction of the >> MI bus_space(9) at least in theory is the right thing but the >> problem is that it's an _K_PI in the first place). >=20 > I am also a big fan of simple API but io(4) isn't too bad, IMHO. :-) >=20 > Jung-uk Kim > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.20 (FreeBSD) >=20 > iQEcBAEBAgAGBQJRwNksAAoJECXpabHZMqHO5dYH/363uqlIUYMhNF2+o/IkNTd/ > 1E3uoRqtBuZc9Nl56aBu2X7qCRe7ndlxIzXwqUbOw/MD+ZuGFMxAemVD8HU485l1 > 17TAIhrLbvZShu7OqjfNYZDY6hi9LJs+7Y0NKFMj/0qQxFZZvrS1/0BrwxmMzQ3E > Jr6LigLaWi5LEekoVEX1Qg7TrXb7fuRXLC3G7SJWtQMi20h/QHpo69wG9+WSugCT > VCPe2t+UrJ07tHa+XFS/SAmPNZHoukIzzkFXzclskqnPXsA6M8eyTG/2SxSoevtS > nob7z4WxlN0Eqkb7EIr04tO+/bu2aKDdg4yCV9SRJ7+9tMruPHFt1TDhuBy1IAg=3D > =3Drv89 > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org"