Suggestion: Windows hardware drivers in Linux kernel

[M.D.]

Warning: This is just a vague suggestion, not a howto nor anything that already works.

As many other Linux users I would appreciate if the Linux kernel had support for various hardware components at least in the time when the appropriate Windows drivers are released. Recently there is a discussion about the Intel PRO/Wireless 2100 WiFi adapter and Intel's willingness (or unwillingness) of releasing drivers for Linux.

And there is a plenty of other hardware which is more or less well supported in Windows (via supplied and ready to use driver), but without any support in Linux.


However in other areas it is already possible to use Windows binary code in Linux enviroment. Remember MPlayer (http://www.mplayerhq.hu/) which supports (among others) many DirectShow and QuickTime (for Windows) codecs using a Wine-derived loader/wrapper (emulating a few necessary Windows functions and translating the codec specific API to MPlayer's API).

If there is some kernel hacker out there, please consider my suggestion: Would it be possible to make some kind of loader/wrapper for using Windows hardware drivers in the Linux kernel (you know, loading the driver, emulating a minimal necessary environment and bridging the Windows specific API [like the network adapter API] to Linux API)?

Before you reply something like "That is totally impossible, do you imagine the complexity..." -- stop!

I can well see all the obstacles. Making such wrapper to work in kernel space is much more complicated than in user space, every little bug can be fatal. Microsoft's documentation of the internal NT kernel to driver API is undoubtedly difficult/expensive to get. Running strange binary code in the kernel probably violates GPL and is generally a security risk.

But as we consider the cons, we should also consider the pros. Thanks for comments.

[MorphiusFaydal]

i have an unsupported network card, and i think it would be great if someone could do this...

yeah..

chris
_________________
Registered Linux User # 309023

vanilla-sources
XFce 4.4 and GNOME 2.20

[zhenlin]

Writing Windows drivers is like Magic. Finding them Driver API Specs is going to be hard, as you said.

WINE for drivers? No. libwine for drivers? Maybe.

Creating all these compatibility packages reduces incentive to write an open-source Linux driver.

Also, I'd like to scream... DUP! But I can't find the previous topic.

[TenPin]

I think this would be a very bad idea simply for the reason that it would disuade manufacturers to write native linux drivers.

I also think most linux developers would either chuckle or groan at the thought. Any time that could be spent doing this would be infinitely better spent writing real linux drivers by reverse engineering windows ones to get the specs.

I would be a fairly interesting project/achievement but in doing so be a monumental waste of time.

[someguy]

i agree with the coments that would state that this is a VERRY bad idea first we have compatibility problems betweem the two osses ( can we say stability issues)??
_________________
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
while [ 1 ] ; do echo "*" | telnet ip.of.print.er 9100 ; done

[BradN]

Not only the stability issues, but I'd imagine it would require writing some sort of wrapper for each different driver type - ie, specific extra code needed for network cards (this might be one of the easier things to support), extra support for sound, etc. The overhead of emulating the windows interface would almost assuredly slow down the driver a lot too. Also, this might lead to a situation where some devices work only on x86 where they could (if they had a proper driver) work on other architectures as well.

[Weejoker]

A good idea (which I have considered before), but as stated above, creating a wrapper around each driver could be troublesome, possibly even requiring VXD/SYS files from other locations (usually from a Windows installation). This is a potential dependency problem, which could lead to legal issues regarding methods to obtain such files. Also, I'd say that using a "hack" around a hardware windows driver could perhaps be suboptimal in terms of performance.

I think there are two options to getting a driver produced:
1) Notify the hardware manufacturer of your desire for a driver, perhaps as a group and see if you can make them sway their decision.
2) Reverse engineer the windows driver to uncover the inner workings and produce a driver from that.

I've seen the latter work on the Epson EPL printer driver (http://epsonepl.sourceforge.net). Two people essentially reverse-engineered the compression and the protocol seperately. Once these two people got in contact they essentially built the driver in a matter of days.

Now I need to wait for someone to reverse-engineer the ESS Tech 1989 modem...

[ferringb]

While I realize you're not after the "this is impossible", there is a pretty major difference in interfaces. The level of wrappers required (one for irc, one for making vfs appear windows native, buffering/signaling) is mind boggling.
Basically, reverse engineering the device (or better yet digging up the chipset specs) would be quicker then writing the wrappers needed, plus they'd not run dog slow due to layers upon layers of wrappers.

[M.D.]

Hello, after several weeks I'm back to this old topic.

Yes, I totally agree that the time spent on programming driver wrapper and emulation layer is wasted when you have the possibility/knowledge/patience to reverse-engineer the Windows driver and write a Linux-native one.

But have you seen some of the Windows drivers? Like that from Intel PRO/2100 Wreless (Centrino)? That .sys has more that 2 MB and I don't really believe that 90 % of it is just junk to fool the hackers.


A native driver is always the best solution and a GPL'ed driver is nirvana. But if there is no real chance to get the driver and you would really like to have the damned piece of hardware working, why not use an emulator/wrapper?


And they did it. Have a look at http://www.linuxant.com/ and enjoy your Centrino WiFi working in Linux. I know, it's not GPL, it's "for free" just for one month, but it works.

[ferringb]

[M.D.]

[yemu]

i don't really like idea because it discourage manufactures from producing native linux drivers. other thing is that buying drivers from linuxant you pay twice - first time for equipment and second for drivers - and lazy producers earn twice - first time when thay sell you the product, and second time when they sell product specs to linuxant.
best regards
yemu
_________________
Centrum Jêzyka Francuskiego VOILA - http://www.voila.edu.pl

[M.D.]

[M.D.]

Finally I had a chance to test DriverLoader with my Intel PRO/2100 Wireless (Centrino) in both managed and unmanaged mode. My kernel is xfs-sources-2.4.20-r3.

The emulated driver is perfectly stable in 2.4.20 (except the rmmod+insmod bug, see my post above), the performance is no issue, too. The power management is not working well yet. I'm not an expert in WiFi technology, so please don't ask we which features are actually supported and which are not, but from an advanced user point of view the wrapper works.

[deviljelly]

try this it is GPL

http://ndiswrapper.sourceforge.net/

[incubator]

I understand very well it isnt advisable to make such wrappers, but then there should be an increased production, either by manufacturers or by other persons, of linux-drivers for hardware.
I mean, just now I did so much trouble to get me a printer that should work well under linux but still doesnt. And it makes me feel like I wasted my money big time