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: Antti Kantee <>
Subject: Re: Fwd: Re: lib/50276: [PATCH] Portability fixes for ossaudio.c
Date: Thu, 24 Sep 2015 22:10:39 +0000

 On 24/09/15 19:50, Robert Millan wrote:
 > El 24/09/15 a les 20:21, Antti Kantee ha escrit:
 >> On 24/09/15 18:15, Robert Millan wrote:
 >>>> Also, if you want to use just ossaudio on Hurd, wouldn't it be better
 >>>> to use the in-(rump-)kernel ossaudio compat translator
 >>>> (sys/compat/ossaudio)?
 >>> There's a big problem with using sys/compat/ossaudio on non-NetBSD:
 >>> since
 >>> it is built in the kernel tree, it includes the NetBSD version of
 >>> <sys/soundcard.h>
 >>> and also other headers like <sys/audioio.h> and <sys/ioccom.h>.
 >> No, it does *not* include NetBSD <sys/soundcard.h>.  The entire point
 >> of the module is to not use it(!)
 > Sorry I used the wrong wording, what I meant to say is that it expects
 > ioctl parameters
 > using a different ABI than the one provided by system soundcard.h.
 > My understanding is that using compat/ossaudio to support userland OSS
 > applications
 > on non-NetBSD systems would require writing an intermediate layer to do
 > the ABI
 > translation. And performing a few minor adjustments to libossaudio is
 > much easier
 > than writing an ABI conversion layer :-)
 The premise for using libossaudio is that you are calling 
 rump_sys_ioctl() (= ABI minus ioctl params).  libossaudio mangles the 
 ioctl params before the ioctl() call ("explicitly").  compat/ossaudio 
 mangles the params after the call but before passing them 
 ("implicitly").  Apart from where the ioctl parameters are translated 
 there is no [fundamental] difference between libossaudio and 
 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?
 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 :/

Home | Main Index | Thread Index | Old Index