From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: alsa on non-linux Date: Tue, 14 Jan 2014 14:23:01 +0100 Message-ID: References: <20140110153700.GC1173@quark.internal.precedence.co.uk> <20140114101709.GB160@quark.internal.precedence.co.uk> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 5D524261987 for ; Tue, 14 Jan 2014 14:23:01 +0100 (CET) In-Reply-To: <20140114101709.GB160@quark.internal.precedence.co.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Patrick Welche Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org 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