[driverloader] driverloader with 2.6.19-rcX

[Linuxant support (Jonathan)]

Hi,

for the version.h vs. utsrelease.h problem on the 2.6.18 kernel and up 
with DriverLoader 2.34 that you have mentioned, a patch is now available 
and it can be installed with the 'dldrconfig --patch' command in a root 
shell. The next version of DriverLoader, which will be available soon, 
will have official support for the 2.6.18 kernel.

We can't guarantee that DriverLoader will work on betas, release 
candidates, etc... versions of the kernel given the fact that the API of 
the kernel is always changing, as you can see. However, problem report 
are welcome.

Thank you for analyzing the problem and witting the summary of it in 
your post, it will definitely help the developers to add support for the 
upcoming 2.6.19 kernel. You are encouraged to send the patch, even if it 
doesn't apply cleanly on DriverLoader 2.34, it will help our developers 
to fix the problem and it could help other DriverLoader users as well 
which might be affected by this problem.

It is possible that we will be able to add support for the 2.6.19-rcX 
kernels in the next version of DriverLoader, but there is no guarantee.

Regards,


Jonathan
Technical specialist / Linuxant
www.linuxant.com
support at linuxant.com



Bob Tracy wrote:
> The driverloader module build process has been broken for a long time,
> but various workarounds to get around the version.h braindamage allowed
> things to work until 2.6.19-rcX for i386 machines.  This is due to
> execve() going away: it was replaced by kernel_execve(), which is not
> exported for use by modules.
> 
> The workaround I'm currently using for 2.6.19-rc2 is to use the x86_64
> approach in driverloader/modules/osservices.c, i.e., OsForkWait() calls
> call_usermodehelper() instead of OsRunThreadSync() to get around the
> need to call OsExec().  Unfortunately, OsRunThreadSync() is still
> required due to a reference in the imported binary blob, but at least
> it's not calling OsExec() in that context.
> 
> I would provide a patch, but there's probably zero chance it would
> apply cleanly against a stock driverloader-2.34 distribution.
> 
> So...  When does the next release of driverloader happen?  All the
> chewing gum and baling wire required to use 2.34 with recent 2.6
> kernels is making me nervous :-).
>