maybe you could drop in for a coffee? I’m at home most days.

I’m close to deciding on a 7.5kW system and live one street away from you with a v large ColorBond roof. I would be very grateful for your input.

Please send me some contract details so we can talk

I use the GPLd version of VirtualBox, without the proprietary add-ons. That only gives me USB1, but its quite sufficient for this sort of work.

Thanks for all your work on qemu/kvm! I have used it a lot for creating virtual clusters to test Samba with CTDB, and its a fantastic piece of work.

Just a note to let you know that qemu-kvm can be used as well instead of virtualbox — it’s completely free (no proprietary addons). Though the GUI virt-manager isn’t as feature-rich as virtualbox’es, we’re getting there

[btw: virtualbox uses a very old fork of qemu and qemu's been evolving at a rapid pace. USB2 support isn't avl. in qemu as well so far, but there's a branch being maintained and collecting patches.]

I’m sorry, but calling a LD_PRELOAD hack a driver is false advertising. Blatantly overriding core system calls in every application, whether it needs to access this particular device or not, is straight plain wrong.

Do you replace core Microsoft Windows DLLs with “hacked” versions of your own? It’s not MS-DOS, it’s Linux. While hooking interrupts (effectively system calls) was the way to get drivers written in DOS, it is not the way it’s done in Linux, or in any other sane OS.

But defending being *that* cheap is ugly.

The -fact- is that your approach, from an engineering perspective, is the most risky for the overall system stability you could have chosen. Fact it, any piece of code -will- have bugs, imagine what happens if I now have a dozen random “drivers” staring to override various libc functions like you do. And you -do- have bugs, see tridge crash, even in totally unrelated applications.

What about exploits ? What about security holes your library might introduce into every other program in the system ?

You seem to be a Mac person, well, I used to be as well, remember how “stable” the system was when we had something like 2 rows of INITs patching every single A-Trap to oblivion, including Apple own stuff as they couldn’t figure out themselves how to get their own stuff working without binary patching at runtime ?

Your approach is wrong and risk prone, and justifying it by “doing the right thing is too hard” isn’t going to fly.

That dup2 is not intercepted is because it is not needed for us. The number of TV applications out there are limited to a few, definitely below 50.
You can go start some tests buy several different TV cards none of them will work with all available TV applications due different API implementation in the background. The clone operation is indeed very tricky to handle, but we took care about this and guess what it works. It was a very tough way to have those things work.

I saw your USB preloadable library, if this would be set globally it would break various applications, just because you intercepted a few syscalls the wrong way (it would deadlock some applications to be more specific). To me that shows that you know the concept of preloading but that you never went into it as deep as we are.

It does not cause any pain to other developers, if you see that our application is running ignore it tell them to remove it and or to ask us about support for it, Linux Kerneldevelopers can do that – they just set the tainted flag and tell the user to remove the module which causes this before helping them further.
Additionally we use to give away tuners to multimedia developers for testing and integrating better support for it, and the feedback we get is very good from beginner users to experienced developers, if there are any problems – especially with external applications – we’ll check it (so far there are none).
Last driver update was just a day ago to increase DVB-S/S2 support, should we tell every customer to recompile the drivers now? That is very much unrealistic, they now just pull the installer for their Ubuntu, Mandrake, Suse, Redhat, Gentoo, etc system and they are done.

This tuner works nearly everywhere including different architectures. You misinterpreted another fact, the fact of writing a driver for different kernel versions.
I’m sure you and some other people are very well aware how to compile kernelmodules, but many users are not. So how to distribute this?
You might remember eeePC or Acer Aspire One netbooks, it came without multimedia stack, without kernel headers, our driver adds support for TV within seconds without even having to take care about the platform. If you compile drivers the manual way you’ll end up with an ABI issue with the audio drivers (for the audio part of analog TV) since Asus never seemed to distribute or document which audio stack they used, we know all the kernelspace issues with regular drivers.
And this particular driver is not only a driver, it’s an application which provides a streaming interface to the TV tuner, the driver interface is an addon.

The discussion should go into the direction, how can this be advanced without the need of preloading. Obviously a driver installable within seconds on all systems with different kernelversions is something that increases the usability of Linux a lot.

We are certainly on the better side when saying that we are only satisfied if everything works, if you checked the installer there’s even a flag to disable preloading – because it was discussed in our support forums, we don’t have to hide what we do.
There’s nothing else to discuss rather than the last sentence here, I just found time to answer this because I’m updating my Mac

I do believe that the device works well for you. That is not the problem.

The problem is that the approach taken, while it works for individual users, is very dangerous and inevitably leads to bugs. What is particularly bad is that those bugs don’t turn up in any code or program that Markus wrote – the bugs turn up in other programs and the developers of those programs get the blame. Markus is inserting his incorrect code into every binary on the system.

I don’t know if you are a programmer, but if you are then perhaps this simple example will help you understand. If you use nm on libmediaclient.so then you’ll see that it intercepts dup() but not dup2(). That means there _must_ be a bug in the code.

To understand this I’ll need to explain how preload based drivers work. A preload based driver catches open() and open64() on a specific filename in /dev, such as /dev/dsp. When it sees an open of that file it remembers the file descriptor number that the open gave, usually in a static local variable.

Then when the program later does a fd based operation, such as read(), write(), mmap() etc, it checks the fd against the list of currently intercepted fds, and overrides the result, thus providing access to the virtual device.

Given the above, now look at what dup2() does. dup2() is a system call that changes a fd from one number to another. So if a program first opens /dev/dsp and later uses dup2() to move it to another fd, then the Sundtek driver will not properly intercept later operations on that fd. Even worse the next open which does then re-use that fd may be intercepted by the SUntek driver and the application could well end up getting audio data in a document file.

Markus could “fix” this bug, but it is but one example of many possible bugs that Markus would need to catch. If he fixed the dup2() problem then he’d next be bitten by dup3(). Then he’d be bitten by the flags to clone() that control sharing of the fs and fd space. Then he’d be bitten by the subtleties of locking and mmap. After that he’ll be bitten by the subtleties of the changes in futex() semantics between glibc versions.

After doing all that, you _still_ can’t get it completely right. The weak symbol aliasing in glibc prevents you from correctly intercepting some library calls that you should be intercepting for this type of “preload” driver. That was a deliberate change by the glibc maintainer (Ulrich Drepper) to make this type of “preload driver” impossible because he thought it is such a bad idea (I know, because I was the one that triggered that change, when I made the mistake of doing a SMB based preload driver for Samba).

It is a neverending task. You end up having to copy more and more of glibc into that “driver”, and then you have to choose what version? Then if bugs are fixed in glibc, you end up with the bugs still present because of the Sundtek driver being loaded.

It is just not possible to write a completely correct preload driver like this. Doing it just causes pain for other developers in very subtle ways.