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

[Olivier Galibert <galibert@pobox.com>]

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\x113589615627420&w=2
  http://marc.theaimsgroup.com/?l=linux-kernel&m\x113225994603627&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