[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: Re: lib/50276: [PATCH] Portability fixes for ossaudio.c

From: Robert Millan
Subject: Re: Fwd: Re: lib/50276: [PATCH] Portability fixes for ossaudio.c
Date: Thu, 24 Sep 2015 20:09:27 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

Hi Antti,

Adding bug-hurd to CC since some of the issues may concern them.

El 24/09/15 a les 16:02, Antti Kantee ha escrit:
On 24/09/15 10:43, Robert Millan wrote:



If Hurd soundcard.h is missing those defines, doesn't it mean that some 
ossaudio programs will fail to compile on Hurd?

Note that most of the defines are missing on Linux too (the only exception being

Aside from SNDCTL_DSP_MAPINBUF/SNDCTL_DSP_MAPOUTBUF potentially being an issue
with Hurd version of <sys/soundcard.h>, the problem is not with applications
but with compiling ossaudio.c itself.

Why isn't adding the missing defines to the Hurd soundcard.h possible?

Not just possible but also desirable IMHO.

My point however isn't about running libossaudio in a specific OS, but rather
that since libossaudio is now potentially usable on just about every system that
could run Rump, I think it makes sense to make libossaudio more portable in 

However if you disagree about that goal, it's no big deal. Users of this stack
can keep using it and carry the patches if needed.

The ABI used by old binaries will not change if you add new definitions, so I'm 
not sure I understand your motivation for patching NetBSD sources here.

Please also note that sys/soundcard.h is a vendor supplied header. Although on
Hurd I expect the developers would agree to improve sys/soundcard.h, in some
cases it's next to impossible.

Consider for example that on Linux this header is provided by the kernel, and:
  - their attitude towards OSS (which they consider deprecated in favour of 
  - their attitude towards user-space device driving on their platform (our 
    discussion about MSI support in UIO comes to mind here).

Robert Millan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]