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

Lee Revell
2006-01-05T18:36:20Z

On Thu, 2006-01-05 at 12:43 +0100, Florian Schmidt wrote:
> On Thu, 05 Jan 2006 02:16:35 -0500
> Lee Revell <rlrevell@joe-job.com> wrote:
>
> > On Wed, 2006-01-04 at 11:37 +0100, tapas wrote:
> > > ALSA's kernel level OSS emulation (as opposed to aoss) cannot provide
> > > software mixing. As aoss cannot provide OSS emulation to all OSS apps
> >
> > Why not?
>
> I did write it out before. aoss is a LD_PRELOAD hack. Apps/libs that
> resolve the system call symbols at build time cannot be made to use
> these calls from a different lib (which is what LD_PRELOAD tries to do).
> A famous example is libc for which a workaround was added (as libc
> offers its own mechanism to intercept fopen() et al.). Others can lurk
> in the background, too. It would even be trivial to write an app that
> aoss will not work with - ever (unless the code be modified - which is
> not an option for closed source apps).
>
> It simply cannot ever work with _all_ apps (as opposed to kernel level
> OSS emu which can be made to work with _all_ apps (at least in
> principle)).
>

OK so you can contrive an example. Have we ever seen a real world app
where aoss can't work?

> Errm, i'm actually wrong about that. Kernel level OSS emu sw mixing
> cannot work together with userspace ALSA sw mixing. I completely missed
> that point.
>
> I still think, the easiest way would be to use FUSE as it gives the best
> of both worlds:

Yep, this does sound like a promising approach. AFAIK it's never been
seriously explored as FUSE is so new.

Lee