ld.so.preload of libmediaclient.so is *very* harmful

[Markus Rechberger]

On Fri, Feb 4, 2011 at 12:34 PM,  <tridge at samba.org> wrote:
> Hi Markus,
>
>  > Do you know what system drivers are for?  Did you ever have the
>  > idea that a devicedriver is available systemwide to every
>  > application and if something's wrong in a kernelmodule the entire
>  > system is affected as well?  Or if an appilcation issues a read()
>  > it will be passed further to kernelspace and if something bad
>  > happens there that the entire system might be stuck?
>
> when a kernel driver has a bug, the kernel puts out an oops message,
> and the end user has some hope of working out what driver is causing
> the problem. They at least know that it is a device driver that is
> causing the issue, and they can try to narrow it down from there.
>
> With your "driver" there is no such mechanism. You just get strange
> behaviour in completely unrelated system processes. Those system
> processes then get blamed, and the user has no reasonable way of
> knowing that the problem is in your "driver".
>
> The Linux driver development tools are not great, but trying to bypass
> them just makes things worse for other developers.
>
> If you can't develop a real driver, then maybe take Greg up on his
> offer?
>
>  http://www.kroah.com/log/linux/free_drivers.html
>

if you know any applications which do not work because of our driver
let me know.
We like to improve our work :-) but I'm afraid that you won't find
anything with the
current driver (for everything older I can also say I found bugs with
older Samba releases
that won't help anyone :-).

Unfortunately that website from GKH is far away from reality, we tried
opensource
drivers in kernelspace but failed because many manufacturers ship
Linux distributions without Multimediastack
support at all. In order to have support for those devices we don't
even need to know the kernelversion and it will work.

My personal point is everything has to work, I don't care about the
rest, there will always be people who prefer green over blue :-)

And please read what I write, try to understand it, don't twist it
around the way you want it to have and quote it somewhere else. This
won't lead anywhere except kindergarten maybe. No developer knows
everything, especially you otherwise you wouldn't have advised to use
a broken interface (CUSE) where I showed you the kernel backtrace that
it is broken with many distributions, or switch to widely incompatible
kerneldrivers.
We'll not go back to 1994, an acceptable alternative has to provide at
least the same flexibility, otherwise it's a sign that glibc is truly
missing something.

If someone has considerations about this he is invited to visit us for
reviewing the library in question.

Thanks alot for your support :)
Markus