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

On Fri, Jan 06, 2006 at 09:26:42PM +0100, Jaroslav Kysela wrote:
> 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)

Dmix _is_ a context switch, you know?


> 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.).

You only get context switches if you go through plugins, which is
pretty much the same way alsa currently is, isn't it?


> 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).

The ALSA kernel API better go documented soon or I'll have to document
it myself. Security and openness-wise, it is just not acceptable to
have a user-accessive kernel API kept under wraps.


> > 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,

After reverse-engineering your kernel interface. How convenient.


> but this library will not be supported with our team.

Of course. You won't have to though, since you claim the API is
upwards compatible.


> The ALSA from 1.0 version is
> binary compatible (even 0.9.0rc4+ linked applications should work) and old
> ioctls are emulated.

Good.


> 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.

Every application that does inter-process communication has potential
protocol-level security issues. Current ALSA creates two shared
memory zones and one semaphore with group write permissions. In a
setup where a number of people are in the same group (student group
for instance), are you 100% positive that another user cannot take
control of the running application by writing the right values at the
right time in these zones? Shared memory is the most dangerous
communication vector there is when the other application is
untrustable.


> > 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.

I am indeed not really interested in reproducing the dll hell of
windows in linux. I want simple but really efficient interfaces to
kernel services which then give the possibility to build special needs
libraries over it[1]. At that point you're designing an API for a
specific class of professional audio users and essentially telling all
the other users to bugger off. Bad karma.


> ALSA library can be also compiled as static library, so it's not a
> problem. The ALSA kernel API is stable.

Yeah, that's the second time you're saying that. I'm sure Dave Jones
will be really happy to know that his impressions were mistaken and
his bugzilla was just having hallucinations:
http://marc.theaimsgroup.com/?l=linux-kernel&m=113589615627420&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=113225994603627&w=2


> Also, we use symbol versions for
> all exported functions, so all old binaries linked with the dynamic alsa
> library will work.

Like all the programs I had which segfaulted after the alsa upgrade
that changed set_rate_near. Beautiful versioning there guys.


> Of course, the drivers might change some universal
> control names,

Yeah, also known as "the stick which broke jwz's back".


> 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.

It would be exactly as complicated because of the static link issue.

OG.

[1] SDL, jack and slmodem are I think good examples
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [2.6 patch] schedule obsolete OSS drivers for removal
    ... > recommend to use ALSA API directly with apps. ... At the same time the kernel API itself should be suitable to ... > I, at least, have never thought that the OSS _API_ would die. ...
    (Linux-Kernel)
  • Re: Linux API developer documentation
    ... > the Linux kernel. ... Python has its own API ... ... Libraries and applications will be built against libc. ... If you are looking for the standard posix API, then yes, you would be ...
    (alt.os.linux)
  • Re: [OT] ALSA userspace API complexity
    ... So API might look a bit ... >> complicated for the first glance, but the ALSA interface code for simple ... It means that you are saying that kernel should be bigger and bigger. ... ever have such problems with the OSS API redirection to another API. ...
    (Linux-Kernel)
  • Re: [2.6 patch] schedule obsolete OSS drivers for removal
    ... > a documented kernel interface with optional libraries over it (think ... You're proposing to add more content switches versus current ALSA ... other applications (not only using sound) ...
    (Linux-Kernel)
  • Re: [RFC] Add kernel<->userspace ABI stability documentation
    ... How can something as widely used as sound not work from one kernel version ... something like this is to be the case, at the very least the alsa libraries ... I was looking for something to call the interface between ...
    (Linux-Kernel)