From owner-freebsd-arch@FreeBSD.ORG Tue Jun 18 10:56:16 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 E78EA2E0; Tue, 18 Jun 2013 10:56:16 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by mx1.freebsd.org (Postfix) with ESMTP id 98F631F55; Tue, 18 Jun 2013 10:56:16 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id f6so2363659qej.9 for ; Tue, 18 Jun 2013 03:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=r+eby7vyGNQFQ27sCOcs9rPTM29YbxNrhVg/3z6PWGg=; b=jnbrwSDac7yEKi00JZZF0rXYIoZcss2bT6JAALcfN0gcLN3aCW/tcrLLRKvrpZPoeU 54JcW174q7GkFc6FX04DpZbDxC99iFTPo506VU0LbINbsXF7pKxuooWs11PxTXghga0E aT+RLCz2qAoFaJLr2MEF51qidl50jAZF/hcJt4nW7efrWKUH4Ds+xPzKD2tGucOtL7Wm 4rKV2HTeJj5f5aWU5qtY255akukXSM3qB60wqIMX+O2EFAfesXm/HFqLznbqyMBBAePA TGimlEJy732Tr8689GQAb8/QE+J/aXCVqwHCpbR1X/isn6OgYP+cIAl3e8S51p99TSKQ dTYg== MIME-Version: 1.0 X-Received: by 10.224.211.8 with SMTP id gm8mr15822474qab.77.1371552975583; Tue, 18 Jun 2013 03:56:15 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.117.3 with HTTP; Tue, 18 Jun 2013 03:56:15 -0700 (PDT) In-Reply-To: <51C0345E.4000309@freebsd.org> References: <51C0345E.4000309@freebsd.org> Date: Tue, 18 Jun 2013 12:56:15 +0200 X-Google-Sender-Auth: WJzJ_SMyGA6o5Mm9ABmeZMnpPHc Message-ID: Subject: Re: Bus space routines From: Robert Millan To: Niclas Zeising , Bruce Evans Content-Type: text/plain; charset=UTF-8 Cc: arch@freebsd.org 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 10:56:17 -0000 Hi Niclas, Thank you for bringing this up. 2013/6/18 Niclas Zeising > 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 Yes, this was my original patch. I wrote it to fix a problem on GNU/kFreeBSD. As always, I took care to do things in a way that would be likely to work on FreeBSD as well (rather than, e.g. using ). > 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 Actually, based on previous discussion my understanding was that it's in*/out* which wasn't ment to be used in userland: http://lists.freebsd.org/pipermail/freebsd-arch/2012-March/012470.html I'm adding Bruce Evans to CC, as he participated in that thread. I expect he can provide some insight. > 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. Well, there's part of truth in this, but it's not quite the point I was trying to make. Yes, GNU/kFreeBSD is an hybrid system, and as such in some cases it is forced to support two namespaces, because sometimes the semantics from each system just don't get along: >>>> FreeBSD code: outw(port, data); >>>> Glibc code: outw(data, port); We can cope with this problem (mostly) by forcing programs into the namespace they were expecting. But this is IMHO a more general issue, and is not just relevant to GNU/kFreeBSD. The problem is: what happens when someone reuses this code somewhere else? Then we're in for some very ugly trouble. Undefined I/O behaviour is not something I'd like to happen without notice simply because I ported some code from one system to another. I think the BSD world did the right thing by introducing new semantics. Plus they're also more portable (on the hardware sense), have a look, e.g.: static __inline void bus_space_write_1(bus_space_tag_t tag, bus_space_handle_t bsh, bus_size_t offset, u_int8_t value) { if (tag == X86_BUS_SPACE_IO) outb(bsh + offset, value); else *(volatile u_int8_t *)(bsh + offset) = value; } So why not just use those? It seems very natural to me that if you have something which is unambigous and reliable, you use this instead of something else which is prone to nasty errors. -- Robert Millan