[driverloader] driverloader with 2.6.19-rcX
Linuxant support (Jonathan)
support at linuxant.com
Wed Oct 18 14:58:19 EDT 2006
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
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.
Technical specialist / Linuxant
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 :-).
More information about the driverloader