Re: alsa on non-linux

From: Takashi Iwai <tiwai@suse.de>
To: Patrick Welche <prlw1@cam.ac.uk>
Cc: alsa-devel@alsa-project.org
Subject: Re: alsa on non-linux
Date: Tue, 14 Jan 2014 14:23:01 +0100	[thread overview]
Message-ID: <s5hsisqsnnu.wl%tiwai@suse.de> (raw)
In-Reply-To: <20140114101709.GB160@quark.internal.precedence.co.uk>

At Tue, 14 Jan 2014 10:17:09 +0000,
Patrick Welche wrote:
> 
> On Mon, Jan 13, 2014 at 01:13:23PM +0100, Takashi Iwai wrote:
> > At Fri, 10 Jan 2014 15:37:00 +0000,
> > Patrick Welche wrote:
> > > 
> > > I am currently successfully running alsa-lib 1.0.22 with oss plugins on
> > > a non-linux box. The advantage is that programs written to use libasound
> > > work.
> > > 
> > > I just tried to update alsa-lib, and see that now alsa-lib directly
> > > includes headers like linux/types.h, and all protection, such as
> > > 
> > >   #if defined(LINUX) || defined(__LINUX__) || defined(__linux__)
> > > 
> > > has been removed. This means that compilation on non-linux is
> > > essentially impossible.
> > > 
> > > Is it that there is now a different way of obtaining that alsa lib
> > > front end / oss back end layer?
> > 
> > Feel free to submit a fix patch :)
> > 
> > The inclusions of linux/*.h are mostly due to laziness.  If a patch is
> > confirmed to work on both Linux glibc and others, we'll happily take
> > that patch.
> 
> I started out, writing the attached patch in November, but then it looked
> as though the boundaries of application library interface and linux sound
> chip driver had become so blurred that I thought that a decision had been
> taken to bin all OSes bar linux, hence the question. Can you give me a
> hint on how you think it is supposed to work? (Which bits you know are
> meant to be linux only, as they are the actual drivers, which bits you think
> should be OS agnositic...)

The Linux-specific part is only the type definitions.  There are a few
Linux-kernel specific types and modifiers like __kernel_off_t or
__bitwise, which are provided in linux/types.h.  This is the only
reason of linux/types.h inclusion.  The inclusion of linux/ioct.h. can
be well replaced with sys/ioctl.h, I guess.

BTW, about your patch: I don't think it's good to embed the endianness
in asoundlib.h.  It makes the header file appearing differently,
depending on the architecture, which is rather confusing.

Takashi