Re: [Alsa-devel] OSS driver removal, 2nd round

[Jan Engelhardt]

>
>There is an ALSA tool called aoss.
>What this does is hook any calls the application does to
>fopen/fwrite/fread/fclose/open/close/read/write/ioctl etc. and detects
>any calls to open /dev/dsp and /dev/mixer and diverts them to use
>alsa-lib. This therefore manages to divert the applications use of
>/dev/dsp before it even reaches the kernel. This therefore gives the
>application full use of all the alsa-lib features. So, for example,
>4-channel output would work in this mode. But, and this is the bit we
>need help with, if the application uses dlopen to dynamically open a
>plugin, the plugin's calls to open/close/read/write etc. are not hooked,
>so the application fails.
>
>Is there any way to also hook the IO calls of dlopened plugins?
>
Well you could patch the affected plugin's .dynstr table so that it should at
best try to call a function that has not yet been defined somewhere else (like
open); IOW, you change the .dynstr entry from 'open' to say 'my_open', and
regularly include libmy.so through e.g. LD_PRELOAD.

Of course the MD5 won't match afterwards, but I think the plugin should execute
as usual afterwards, since .dynstr is something no app should rely on.


Jan Engelhardt
-- 
-
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/