linux-kernel - Re: Is it time for remove (crap) ALSA from kernel tree ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87lke3g1kg.fsf@hades.wkstn.nix>
Date:	Thu, 28 Jun 2007 23:24:15 +0100
From:	Nix <nix@...eri.org.uk>
To:	Adrian Bunk <bunk@...sta.de>
Cc:	Olivier Galibert <galibert@...ox.com>,
	Takashi Iwai <tiwai@...e.de>,
	Tomasz K?oczko <kloczek@...y.mif.pg.gda.pl>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: Is it time for remove (crap) ALSA from kernel tree ?

On 28 Jun 2007, Adrian Bunk outgrape:
> Linux software not supporting ALSA has becoming quite esoteric.

Indeed. This is why I haven't moaned much (or at all): aoss is ugly,
sure, but you only need it for those rare apps which run for a long time
or while other sounds are playing, on non-mixing-capable hardware, for
which the in-kernel emulation won't suit... and most non-sound-
specialist apps are using esd, arts or pulseaudio anyway, so that does
the mixing for you (and pulseaudio also does it for every ALSA app if
the pulseaudio plugin is installed). And the sound-specialist apps
are the ones that actually *benefit* from ALSA's ludicrous degree of
low-levelness, so they're using it, or something even more flexible
like JACK.

I use quite a lot of sound apps, and I can count the number of times
I've had to use aoss in the last year on the fingers of one hand.

But still it's conceptually ugly. Doing stuff in userspace, yes: but the
kernel should be calling *back* to userspace to do it, not depending on
things being done in the client's address space by a client library for
proper function. (See also others' rants regarding the nasty
quasi-unstable nature of the ALSA ioctl() kernel interface...)

Isn't this sort of big user-to-and-from-kernelspace data-transfer job
what we have relayfs for? (Or is it unidirectional?)

> common. And that's exactly the case where users run into the results of 
> the "internal implementation detail" that their application used the 
> in-kernel OSS emulation instead of ALSA resulting in exactly these 
> problems.
>
> There is also a userspace OSS emulation for ALSA not suffering from 
> these problems.

The problem is that the user has to *know* to run `aoss'. The in-kernel
OSS emulation is actually nicer than thr userspace one because it works
automatically without the user having to do a damned thing. If only it
(and ALSA as a whole) called out to userspace again to mix, we could
presumably ditch aoss, and the user would never need to care which API
the author chose to use. (There are still complexities involving reading
the user's .asoundrc to consider, but most users don't use that so
wouldn't need aoss for anything anymore.)

And then all these damn silly ALSA/OSS flamewars could go away.

> It's not my decision whether or not to remove the in-kernel OSS emulation, 
> all I'm saying is that removing it might actually result in less users 
> having problems.

I think it would lead to *more* problems. The in-kernel emulation
*almost* Just Works, and surely the ideal we should aim for is an
emulation that Just Works.

-- 
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/