The current state of affairs are disappointing, but I kinda saw this coming. The only real business model here is one of support and that looks to be all but officially gone now...
There were many reasons I wanted to make sure the driver source was released (as seen in the GPL thread), primarily for moral and legal reasons, but also because I feared Tom would perform another disappearing act and we'd never get to see the source.
Anyway, I spent some time looking at the driver source trying to figure out how it worked and what would be involved making it hardware agnostic. I was able to get it compiled and "working" on my gentoo system, but I never got to the point where I could manage an array with it. The driver is written in a very non-generic way. It's obvious Tom never intended to make the driver open source and it's built to work only with his "proprietary" management tools. For example, you have to load the driver with the list of devices in the array (because there's no persistent store for a config file...) and all the management is done through a /proc interface rather than ioctls.
Oh, and for the record, I don't own any UnRaid products. I've never seen any of the management tools, only the /usr/src/linux-2.4.31 tree as was sent to me by another member here.
I was also curious of the effort required in porting the UnRaid driver to the 2.6 kernel. Unfortunately, porting the driver to 2.6 would be a massive undertaking that I have neither the skills or time for. My suggestion would be getting the source code in the hands of some real kernel developers and see if any want to support the concept. My guess is that it would be better (more appropriate?) to make "unraid" a device-mapper target. But you might have a hard time keeping the "standard filesystem" feature where you can just pull out an UnRaid drive today and stick it in any Linux box with reiserfs support and read the drive... I dunno.
I also have a hard time believing you'll see any performance improvements with the driver in the 2.4 kernel simply because of the single shared I/O queue and scheduler limitations. The 2.6 kernel makes huge improvements in these areas which should provide for better concurrent read/write performance.
I'm a HUGE fan of the the UnRaid concept and I'm happy to provide assistance where and when I can on any completely open-source fork of this product, but my time is extremely limited these days. So get busy, Joe
-Brian