Hardware manufacturers which refuse to release programming information are a
constant source of frustration for Linux users. Without that information,
writing a Linux driver is nearly impossible. As a result, Linux users are
unable to use the hardware in question, and the vendor loses potential
A company called Linuxant has been offering a product called
DriverLoader which is intended to relieve some of this frustration, at
least for network devices. It is a kernel module that serves as a wrapper
for Windows NDIS drivers. Using DriverLoader, a network device with a
Windows driver can be made to function under Linux. There are, needless to
say, a few
objections that one could make to this product, one of which being that
DriverLoader, itself, is not free software.
If the non-free nature of DriverLoader is your only objection, however,
there is an alternative called ndiswrapper, which is
licensed under the GPL. ndiswrapper is clearly in a very early stage of
development, but, as its author (Pontus Fuchs) notes, "it works for me."
With a bit of work, it could probably be made to work for a lot of other
users as well.
The ndiswrapper module, when loaded, starts by registering a special
purpose "misc" device; its only real reason for existing is to export an
ioctl() call which can be invoked to load an NDIS
driver. This call accepts the driver code from user space, performs the
necessary relocation, and sets it up as Linux network device.
In the modern world, using the register_firmware()
interface might have been preferable to creating another ioctl()
call, but that can always be done in the next revision.
Once the driver is loaded, ndiswrapper provides two separate glue layers to
make the NDIS driver actually work. The first provides a set of
net_device operations which can be invoked by the networking
subsystem; these translate the requested operations into the calls that the
NDIS driver will be expecting. At the other end, the wrapper code must
provide emulation functions for a few dozen Windows routines that the NDIS
driver will call. These map the requested operation (allocate an
interrupt, remap I/O memory, feed a received packet into the kernel, etc.) back
to their Linux equivalents.
All told, it is not a huge amount of code. The NDIS API is well enough documented
that the requisite glue code could be written without a great deal of
The wrapper approach to device support is far from optimal. Performance
and reliability cannot be improved through the addition of glue layers, and
many users will be unenthusiastic about shoving proprietary code - Windows
code, even - into their Linux kernels. There is also the risk that
hardware vendors might conclude that the existence of wrapper code frees
them from the need to worry about Linux driver support at all. Against
these disadvantages one can point out that the wrapper will enable Linux to
be used on systems that would otherwise be inaccessible to it. This sort
of wrapper module could also, with little effort, be turned into an ideal
platform for the reverse engineering of unsupported hardware. A module
like ndiswrapper may be a hard sell for the mainline kernel, but some users
will certainly be glad that it is available.
to post comments)