Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030247AbWAHNVc (ORCPT ); Sun, 8 Jan 2006 08:21:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752625AbWAHNVc (ORCPT ); Sun, 8 Jan 2006 08:21:32 -0500 Received: from dspnet.fr.eu.org ([213.186.44.138]:52490 "EHLO dspnet.fr.eu.org") by vger.kernel.org with ESMTP id S1752624AbWAHNVb (ORCPT ); Sun, 8 Jan 2006 08:21:31 -0500 Date: Sun, 8 Jan 2006 14:21:22 +0100 From: Olivier Galibert To: Martin Drab Cc: Takashi Iwai , ALSA development , linux-sound@vger.kernel.org, LKML Subject: Re: [OT] ALSA userspace API complexity Message-ID: <20060108132122.GB96834@dspnet.fr.eu.org> Mail-Followup-To: Olivier Galibert , Martin Drab , Takashi Iwai , ALSA development , linux-sound@vger.kernel.org, LKML References: <20060104030034.6b780485.zaitcev@redhat.com> <20060108020335.GA26114@dspnet.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1558 Lines: 42 On Sun, Jan 08, 2006 at 03:26:18AM +0100, Martin Drab wrote: > On Sun, 8 Jan 2006, Olivier Galibert wrote: > > > > And if the application doesn't support, who and where converts it? > > > With OSS API, it's a job of the kernel. > > > > Once again no. Nothing prevents the kernel to forward the data to > > userland daemons depending on a userspace-uploaded configuration. > > I think that the point was, that switching from userspace to kernelspace > then to userspace again and back to kernelspace in order to do something, > that could have been done directly in the userspace, and though could save > those two unnecessary switches, is an unnecessary overhead, which may not > necessarily be that insignificant if it's done so often (which for > streaming audio is the case). You all seem to forget that dmix is in userspace in a different task too. > Why doing things complicated when there is no evident gain from it, > or is there? No evident gain? Wow. What about: - stopping crippling the OSS api - having a real kernel api for which you can make different libraries depending on the need of the users - stop making a fundamentally unsecure shared library mandatory - opening the possibility of writing plugins to people without a PhD in lattice QCD. and that's just a start. OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/