lkml.org 
[lkml]   [2006]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [2.6 patch] schedule obsolete OSS drivers for removal
    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/

    \
     
     \ /
      Last update: 2006-01-06 21:29    [W:5.717 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site