Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Jaroslav Kysela <perex@suse.cz>]

On Fri, 6 Jan 2006, Olivier Galibert wrote:

> On Fri, Jan 06, 2006 at 03:40:26AM +0100, Diego Calleja wrote:
> > Amazing - even windows is getting sound mixing out of the kernel
> > in windows vista because they've learnt (the hard way) that it's
> > the Right Thing and linux people is trying to get it in?
> 
> You misread.  Most people just want to have things work like they
> should have for years.  Technical people, at least Marcin and I, want
> a documented kernel interface with optional libraries over it (think
> libX11 vs. the X Protocol, or glibc/klibc/uclibc/libc5 vs. the system
> calls), and then behind that have the kernel route the data to
> userspace demon(s) or the hardware depending on root-level setup and
> configuration.

I got the point, but the audio is very specific that it requires realtime 
scheduling. Even graphics is not so tied with realtime, because a 
scheduling gap does not end with error or very ugly misbehaviour (pops) 
like in audio.

You're proposing to add more content switches versus current ALSA 
implementation:

user space <-> kernel

While your daemon requires:

user space <-> kernel <-> user space (daemon)

So your solution is even more realtime and proper scheduling dependant.
Unfortunately, Linux kernels still do not have perfect realtime behaviour 
(mostly due to broken drivers etc.).

Also, the API is completely irrelevant from this scheme. If daemon does 
everything, the ALSA kernel API can go public and documented (altough I 
still does not agree with it - see bellow).

> ALSA does not have a documented kernel interface nor an optional
> library but a mandatory library.  A highly complex, ipc-using library

It's also not very true. You can create your own ALSA library, but this 
library will not be supported with our team. The ALSA from 1.0 version is 
binary compatible (even 0.9.0rc4+ linked applications should work) and old 
ioctls are emulated.

> with no security audit that I could find with google.  A library for
> which people do not seem to care about compatibility with previous or
> future kernel versions, which means it _has_ to be shared.  And shared
> libraries are just unacceptable in some contexts, like distributing
> binaries outside of a specific linux distribution[1].

I'd like to point that this code runs with standard user priviledges. I 
think that the security things are and should be in a different place (in 
the kernel). If IPC is broken, other applications (not only using sound) 
might be broken. If administrator (root) creates wrong configuration files 
for alsa-lib - we cannot do anything. It's a human error. The same problem 
is if you have this code in kernel. It can be bad (even more than in the 
user space - you can shutdown whole system) too.

> At least OSS, with all its flaws, is a documented kernel interface.
> You can static link a oss-using program, whether it uses it directly
> or through interfaces like sdl-audio, and it will just work.

Please, see your words. You're simply anarchistic. You replaced 
flexibility of dynamic library with a possibility to have static binary.

ALSA library can be also compiled as static library, so it's not a 
problem. The ALSA kernel API is stable. Also, we use symbol versions for 
all exported functions, so all old binaries linked with the dynamic alsa 
library will work. Of course, the drivers might change some universal 
control names, then different configuration files for alsa-lib should be 
used, but it's a different point and we're working also on this 
compatibility to avoid these problems in future. But the standard stereo 
sound work all the time (I speak about 5.1, S/PDIF devices).

Also note, that if OSS had the API in userspace from the first days,
the emulation or redirection of this API to another API or user space 
drivers wouldn't be so much complicated nowadays. Bummer.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
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/