Hi,I am wondering if there is any way to run a 32 bit ndiswrapper binary on a 64-bit Linux system? For example could something like ia32-libs be used? If not, how much effort would be involved to get this to happen, would this require kernel changes, or just changes to ndiswrapper?Thanks,Mark
From: Pavel Roskin <proski@gn...> - 2011-09-15 19:12:06
On Thu, 15 Sep 2011 13:31:48 -0400
Mark _ <mark_aok@...> wrote:
> Hi,I am wondering if there is any way to run a 32 bit ndiswrapper
> binary on a 64-bit Linux system?
I think it should be possible to run ndiswrapper in a 32-bit virtual
machine using a device exported by the host. The virtual machine could
have another network interface and act as a router with NAT for the
> For example could something like ia32-libs be used?
The is no ia32-libs equivalent for the kernel. All the kernel code
is supposed to run in the same CPU mode.
> If not, how much effort would be involved to get
> this to happen, would this require kernel changes, or just changes to
Let's consider the possibilities.
If ndiswrapper is 32-bit, another wrapper between ndiswrapper and the
kernel would be needed to change the CPU mode and translate the code.
The kernel may assume that all kernel code is 64-bit. Some changes may
be needed to account for that. Essentially, it would be a project to
load 32-bit modules into a 64-bit kernel. My estimate is that it would
be an effort compared to writing ndiswrapper itself. It's hard for
me to imagine any benefits for any other modules.
If ndiswrapper is 64-bit and runs the Windows driver natively in the
kernel mode, it would need to switch the mode in the interfaces between
Windows and Linux functions. Those interfaces are already written in
assembler, so different versions would be needed that would switch the
CPU mode. ndiswrapper will need to be compiled with special flags so
that Windows types are defined as they would be on 32-bit Windows.
Again, there is a problem with the kernel preempting 32-bit kernel code.
That may be tricky to solve.
ndiswrapper could be changed to run Windows code in userspace like a
process. Then ndiswrapper would need to incorporate support for a new
executable format. ndiswrapper would need to handle exceptions from
the Windows code trying to access privileged operations, such as
writing to ports. When running 32-bit drivers, ndiswrapper would need
to provide compatibility versions of all functions called by the
driver. The kernel would have no problem preempting 32-bit
userspace. This approach may be useful to make ndiswrapper more
acceptable for users, even without considering 32-bit support on 64-bit
kernels. It's something that could be attempted, but the effort would
ndiswrapper could include an emulator for i386 architecture and run
drivers in the emulator. That would make ndiswrapper useful on
non-x86 architectures, such as ARM. On the other hand, it could make
ndiswrapper slower. Also, bringing an emulator to the kernel code
would not be taken with enthusiasm by the kernel folks.
To sum up, I don't see any easy solutions. And of the hard solutions,
the only one that is potentially maintainable (that is, somebody could
be found to keep that code working and fix bugs once it's implemented)
is moving drivers to the userspace.