Re: driverloader with 2.6.24-rcX

Hi,

as far as I know, you have described all the known issues we have also 
experienced with DriverLoader 2.39 on 2.6.24-rc1. We have experimental 
patches for all these issues except for the do_softirq fatal problem, I 
can post them if anyone is interested in them.

More work will be required to make DriverLoader compatible with the 
future 2.6.24 kernel. I will post when a solution to the do_softirq 
problem will be available.

Regards,


Jonathan
Technical specialist / Linuxant
www.linuxant.com
[email protected]



Bob Tracy wrote:
> The driverloader-2.39 release worked great up until the first 2.6.24
> kernel release candidates appeared.  The biggest obstacle to building a
> valid driverloader module seems to be that do_softirq() is no longer
> being exported.  There are other minor fixes to the driverloader code
> required, and as I don't have it in front of me right now, I'll have to
> go by memory :-(.
> 
> The Kbuild process now complains bitterly about changes to CFLAGS, and
> wants out-of-tree builds to use EXTRA_CFLAGS instead.  This means lots
> of trivial mods to the main driverloader module makefile, but the build
> seems to work fine once those mods are made.
> 
> The access_ok macro is now defined in linux/uaccess_32.h and/or
> linux/uaccess_64.h, i.e., the Makefile check for whether that macro is
> defined is incorrectly looking in linux/uaccess.h, which simply points
> to the 32-bit and 64-bit files.
> 
> SET_MODULE_OWNER has gone bye-bye, and all references to it can be
> removed for kernels greater than 2.6.23.  I think this affects two files:
> dldrpci.c and dldrusb.c (if I'm remembering the names correctly).
> 
> I don't know what an appropriate fix might be for the missing do_softirq().
> Fixing everything else allows the build to succeed, but the resulting
> module won't load because of the undefined do_softirq symbol.  If anyone
> can suggest an appropriate fix, I'll be happy to give it a try.
> 
> Thanks!
>