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

Markus Rechberger mrechberger at gmail.com
Fri Feb 4 05:46:38 MST 2011


On Fri, Feb 4, 2011 at 1:01 PM, Volker Lendecke
<Volker.Lendecke at sernet.de> wrote:
> On Fri, Feb 04, 2011 at 12:52:25PM +0100, Markus Rechberger wrote:
>> 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.
>
> How do you handle the case where glibc might develop a
> faster mechanism for one of the calls the lib intercepts to
> avoid the syscall at all, like it has for example happened
> with gettimeofday? Would users still be able to benefit from
> this performance improvement?
>

then we would have to update the driver, right now it works with all systems
preferred mechanism would be to have some hooks directly in the glibc,
but I haven't found the right people for discussing this yet. I have
around 5 years very strong experience with multimedia with linux I
know every single bit of this, the userspace driver basically
reimplements the multimedia API in userspace, that's why it also works
with other operating systems than linux.
It shouldn't be too difficult to use it with CUSE, but CUSE is not
mature enough and the availability is poor as mentioned earlier
already. Once it is mature enough we can give it a go of course. But
for now we do not want to explain why the kernel crashes when using
CUSE.
We do not intercept gettimeofday.

Best Regards,
Markus Rechberger

> With best regards,
>
> Volker Lendecke
>
> --
> 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
>


More information about the samba-technical mailing list