Linux driver nightmare

Linux Hater is right in many of his claims, especially when talking about (non-existing) ABI or even API compatibility of the Linux kernel across versions. Everything is fine as long as your hardware is working out-of-the-box, but as soon as something is not supported out-of-the-box, you're up for a major nightmare.

The past few days, I've been trying to migrate one of our systems from Windows XP to Linux. That box has a few pieces of non-standard hardware installed, mostly sensor systems. Many of those drivers have not found their way into the kernel yet. So let's see..

• Installed Xubuntu 8.04 LTS
• Install kernel headers, build system, etc.
  
• Contact vendor of USB Relais and ask for Linux kernel module
• Surprisingly, got a module that (after minor modifications) compiles and even works!
• Test USB camera. No luck with the Orange iBOT2. Apart from the iBOT2, our framework also supports UVC cameras. Bought a Logitech UVC camera (look out for the "Vista-ready" sticker), which works out of the box in Ubuntu 8.04! Yay!
• Get and compile CAN driver. Seems to work nicely.
• Contact measurement camera vendor, and ask for Linux drivers. Got drivers for a 2.4 kernel. After some investigation, also got experimental drivers for a 2.6 kernel that's been developed on 2.6.13 (and is GPL'ed OSS, btw).
  
• Got the camera driver to compile and load on Hardy's kernel with major modifications. Getting camera info (like chip temperature) works fine, but grabbing images results in kernel panic. Unfortunately, grabbing pictures from the camera is a rather important feature...
  
• Heard rumours that the camera driver works at least up to kernel version 2.6.17
• Try to get kernel packages for something around 2.6.17. No luck on Hardy.
• Clone vanilla kernel git repository, compile kernel 2.6.17. After several attempts, the self-compiled kernel even boots up!
• Compile camera driver again. Grab a first picture! Yay!
• Unfortunately, now the whole rest of the system is pretty broken. Hardy doesn't seem to like a manual kernel-downgrade.
• Got the idea that it might be easier to upgrade a kernel, than to downgrade it. Killed the whole system and installed Xubuntu Dapper 6.06 LTS, which comes with kernel version 2.6.15. Maybe that version will work too, and I won't even need to upgrade..
  
• Compile all external drivers again
• Test if the UVC camera still works. Of course -- it doesn't.
• Download UVC kernel module from svn (there are no snapshots available). Try to compile it -- no luck. Try to find the latest svn revision number that actually compiles with Dapper's kernel by bisection. Compiled and loaded that kernel module.
• Now, let's test with our framework
  
• Oh no -- our framework depends on newer versions of installed libraries (Boost, Qt, etc. pp.) than what is available for Dapper. Grab Boost, Qt, and all other libs from upstream, and compile them.
• Oh no, the cmake build system backported to Dapper doesn't contain all necessary modules either (FindPkgConfig.cmake, others). Get those modules as well. No need to say that the backported cmake build system behaves slightly different to what is installed on Hardy as well.
  
• Compile and start the program. Oh no, crash deep inside Qt. Right -- no OpenGL support without proprietary graphics drivers. Install those as well.
• Test UVC camera. It works!
  

Being a supporter and developer of OSS software myself, I can understand the reasons of the kernel developers for not maintaining a stable ABI (or even API) for kernel modules. But for the user, this is just a major pain, that ultimately renders Linux unusable on many environments.