NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Fwd: Re: lib/50276: [PATCH] Portability fixes for ossaudio.c
The following reply was made to PR lib/50276; it has been noted by GNATS.
From: Robert Millan <rmh%gnu.org@localhost>
To: Antti Kantee <pooka%iki.fi@localhost>, rumpkernel-users%freelists.org@localhost
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: Fwd: Re: lib/50276: [PATCH] Portability fixes for ossaudio.c
Date: Fri, 25 Sep 2015 21:29:23 +0200
El 25/09/15 a les 00:10, Antti Kantee ha escrit:
> Let me put it this way: the sys/soundcard.h that libossaudio installs redefines ioctl so that it catches the ioctl calls before they go hit the kernel. How does that work with a stock soundcard.h from somewhere else? Is there some indirection in your stack somewhere that I'm not aware of?
No indirection, it's simpler than that!
Take for example:
switch (com) {
case SNDCTL_DSP_RESET:
retval = ioctl(fd, AUDIO_FLUSH, 0);
if (retval < 0)
return retval;
break;
ossaudio.c is built using system-wide <sys/soundcard.h>. In turn, the ioctl
constant definitions in <sys/soundcard.h> use the system-wide _IOC macros.
At the same time, ossaudio.c is built using the NetBSD version of sys/audioio.h,
which in turn uses _IOC macros by the NetBSD version of sys/ioccom.h [1].
So in the example above, the "case SNDCTL_DSP_RESET" statement is using
system-wide ABI (both in the sense of system-wide <sys/soundcard.h> and
in the sense of system-wide _IOC), whereas the "ioctl(fd, AUDIO_FLUSH, 0)"
example is using NetBSD ABI (in both senses too).
[1] Note: both files are modified to avoid namespace collision, see
https://github.com/robertmillan/rumposs/commit/dd5596f20126e54b723d312ba5ad182747a38b9b
> The reason I'm trying to find alternate solutions is that I find manually sprinkling ifdefs into the switch quite ugly and fragile and would rather see a cleaner solution. Another way to work around that problem is figure out how to use some sort of translator before the switch so that the primary code path doesn't get polluted with ifdefs ... or to find someone who's not bothered by ifdefs to commit your patch :/
Are you concerned with all ifdefs or just with the ones that get inside
"if () {}" statements? I think the later could possibly be replaced with
ifndef/define before the switch. Does this look better to you?
--
Robert Millan
Home |
Main Index |
Thread Index |
Old Index