Date: Fri, 9 Mar 2012 14:01:25 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Robert Millan <rmh@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] Add compatibility <sys/io.h> Message-ID: <CAJ-Vmonu_ApSd192cjvsW6k3eNNK4Kz=MmAMe_e=zmwbrS8Ayw@mail.gmail.com> In-Reply-To: <CAOfDtXPGPP0reN9NTBw_5%2BNwXZ56Yy0oyx_fH%2BDOvmpc1O%2BQdQ@mail.gmail.com> References: <CAOfDtXPGPP0reN9NTBw_5%2BNwXZ56Yy0oyx_fH%2BDOvmpc1O%2BQdQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I really, really don't like the idea of having the same function have different argument orders based on the include file you're using. That will lead to all kinds of weird ass debugging issues later on. Why is it that we can't fix the upstream code? Adrian On 9 March 2012 13:36, Robert Millan <rmh@freebsd.org> wrote: > This patch adds a compatibility <sys/io.h> that would make it easier > to build on FreeBSD software that has been written for glibc (see > example1.c). > > The functionality in <sys/io.h> is more or less equivalent to > <machine/cpufunc.h> but provides some declarations which are > incompatible with those in <machine/cpufunc.h>. One of these cases is > very unfortunate because it alters I/O semantics, it applies to > outb(), outw() and outl(): > > =A0FreeBSD code: outw(port, data); > =A0Glibc code: outw(data, port); > > The undefined I/O behaviour that could potentially result from this is > very scary. Because of this I've written a few checks to prevent both > headers from being used at the same time. Overall, aside from the > portability benefit, my proposed addition has some less obvious > side-effects: > > =A0 =A0 Desireable side-effect: Adding <sys/io.h> would break > buildability of code that attempts to use both headers at the same > time _WITHOUT_ changing the outw() call semantics (see example2.c). > > =A0 =A0 Undesireable side-effect: Adding <sys/io.h> would break > buildability of code that attempts to use both headers at the same > time, and was otherwise fine due to conditionalized outw() calls (see > example3.c [1]). > > [1] I found a real case where this happens, in > sane-backends-1.0.22/backend/umax_pp_low.c. In case my patch is > accepted, I commit to provide a fix for sane-backends and also to > adjust Debian GNU/kFreeBSD headers to follow the same route [2]. > > [2] This means: reenable outb(), outw() and outl() in > <machine/cpufunc.h>. Currently we provide both headers, but outb(), > outw() and outl() are entirely disabled. I think it's better for both > projects to provide <sys/io.h> since the majority of code out there is > written with GNU/Linux in mind. > > Attached patch is tested against HEAD with "make universe". > > -- > Robert Millan > > _______________________________________________ > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmonu_ApSd192cjvsW6k3eNNK4Kz=MmAMe_e=zmwbrS8Ayw>