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

[Markus Rechberger]

On Fri, Feb 4, 2011 at 12:20 PM, Volker Lendecke
<Volker.Lendecke at sernet.de> wrote:
> On Fri, Feb 04, 2011 at 06:51:08AM +0100, Markus Rechberger wrote:
>> 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?
>
> For one point I would like to hear your arguments:
>
> Performance.
>
> When a driver is installed in the kernel, it is only ever
> touched when the device is really used. If a library hooks
> into open(), read() or so, even if it passes it down 1:1 to
> the kernel because it does not affect the library's device,
> it must make that decision. Imagine we had the majority of
> all devices implemented this way, this would stack up
> considerably.
>

it only intercepts calls to /dev/videoN, /dev/radioN, /dev/dspN,
/dev/dvb, everything else will go
straight to a syscall eg. syscall(SYS_open, __file, __oflag, mode);

I can imagine that this is even faster than with libc itself since the
libc comes later in the chain.

Best would be to include this approach directly in the libc to allow
hooks, I sent an email to Ulrich Drepper earlier already but didn't
get any reply. I'm happy to discuss this mechanism (or a mechanism
which can be included in libc directly). The historical discussions
did not go nearly as far as where we are already with it.
The driver works entirely in userspace, and the same driver also works
on Apple and we even have FreeBSD builds for it as well. Aside of that
it also works well on ARM, MIPS and PowerPC, we just release one
driver per architecture (and everyone is using the same driver build).
This makes debugging across multiple kernels and multiple
architectures very easy for us. Even supporting customers if they have
issues is no problem.

CUSE has been mentioned, cuse is not acceptable.
CUSE is unstable with 2.6.33 ( http://pastebin.com/UBemuMB1 ) we
reported those issues but did not follow up.

The current driver even works with 2.6.18 delivering the latest
features (note it's not even possible to compile all the latest
kerneldrivers with those old kernels, but we have customers using it
with it).

We'd be happy to implement an alternative way but it has to deliver
the same flexibility at least - meaning we don't care which
kernelversion the enduser is using, and the driver installation (which
provides support for DVB-C, DVB-T, DVB-S/S2, ATSC, ISDB-T, AnalogTV,
FM Radio, Composite, S-Video devices)  must not take longer than 10
seconds. Everyone else who doesn't like that should not go for it.

Best Regards,
Markus

> With best regards,
>
> Volker
>
> --
> SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
> phone: +49-551-370000-0, fax: +49-551-370000-9
> AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
>