OSDev.org

Am I right in thinking that a new operating system will not be able to use device drivers from the device manufacturers - that is, drivers are written specifically for an operating system?

Is it possible, with a bit of sneaky manipulation/emulating and interception, that device drivers from a different operating system can be used?

Google "ndiswrapper" and "project evil".

Also, Project UDI.

And (shamless plug) EDI.

Thanks. Certainly looks as if it's possible!

Standard device drivers (ie. Windows, and in some cases Linux/*BSD) cannot be simply dropped in to a new kernel, UDI/EDI still require drivers to be specifically written for them, just targetting the standard API (similar to POSIX with UNIX variants) instead of a specific kernel.

If you want to take advantage of existing device driver libraries then have a look at ReactOS/Wine for Windows or the Linux module interface. ReactOS will support Windows drivers by providing an identical kernel API which you may be able to tear out and integrate into your own [hybrid/monolithic]kernel. The Linux module interface should be reasonably well defined (although it apparently fluctuates frequently) and you may be able to implement a 'works-alike' for that to plug in the modules, but the modules may need to reach into the kernel to access internal functions which may mean implementing portions of the linux kernel in your OS. Other than that there's EFI which is meant to include minimal system independant drivers embedded in the hardware but you'll most likely only get that on expensive new hardware, the Apple Intel iMacs have it IIRC.

One possible exception is that nVidia distributes a binary chunk driver which has glue code built against it to attach it to the linux/BSD[/Windows] kernel, it might be possible to replace the glue code to fit it into another system but that still leaves the problem of implementing a replacement OpenGL library to interact with the driver.

guest wrote: One possible exception is that nVidia distributes a binary chunk driver which has glue code built against it to attach it to the linux/BSD[/Windows] kernel...

Be aware that this is the hottest battlefield of the GNU people right now. They want to remove that very possibility. They call it "tainting the kernel"... If they get their wish, no Linux driver will be usable for any other OS, unless you want to follow each of the changes they do to their precious we-won't-make-it-stable kernel ABI.

That's a bit selfish, isn't it?

But not really surprising. They've been adamant about anything that might actually benefit other operating systems. Like, read this and notice how RMS uses the terms "Free Software" and "Linux" as if they were one and the same thing, and doesn't spend a second on how UDI might have leveled the playing field to open up the OS market for competition on technical merits instead of driver base...

(Calm down, Solar, you've ranted against this bunch often enough... breathe... relax... better. ;D )

UDI would be the best thing to happen to the free OS community, BUT this would suck for open source driver writers who would go out of business, "free" drivers would dominate over "open source", so it is good for us OSdever's, but not the those who spent all this time making drivers that will get beat out by "free" drivers

P.S. I hope that was right

imho allowing plugable drivers in which you simply write the Gluecode is a very good idea.

GLneo wrote:...BUT this would suck for open source driver writers who would go out of business...

Writing OSS drivers isn't a business. If you're lucky, you get cross-financed by a company that makes money elsewhere, e.g. by selling Linux distros, but you don't get anything for writing the drivers except a warm, fuzzy feeling.

Note that nothing keeps you from putting an UDI driver under GPL. The only difference between a GPL/UDI driver and a GPL/Linux driver is that other people could use the UDI driver, too. And please don't tell me there's hardware out there that Microsoft needs OSS people to write drivers for, so the ones you're hurting with not embracing UDI in Linux are SkyOS, Zeta, Clicker etc., not Windows or Apple...

Of course, after we moan about legal and political factors, there's still the fact that a UDI environment must sandbox drivers in the rough equivalent of a small separate operating system. For that much effort you might as well just fully virtualize the driver to fool it into thinking it's running on bare hardware.

If UDI were practical, I'd be implementing it right now rather than coming up with an alternative that most people think *still* isn't practical .

Its very easy to get round this problem, you take a cheap, common device for things like sound, graphics etc, with well documented driver interfaces and you write drivers for it, as per your OS design.

If people want to use your OS to the full, they should buy the cheap hardware spec, if not its there loss.

You should all as OS Dev's write a "OS dev's PC spec doc", so you have the same cheap hardware, if linux etc, had done this, the hardware makers would have soon court on, that how the SB came about.
So take a vote for each device, once you all agree, write doc for coding drives etc.
Then just think how good it would be if 50% of member had the same basic spec PC.

PS: This link is a typical example of a useless talking shop ( or in this case doc) Project UDI.
Doc like this, come about from people, who do not like coding, but love to type, if the same effort was put into writing drivers, with all OS dependant code in a separate file, that would be more usefull.

Personally, I think more time needs to be spent writing useful documentation of the drivers. Instead of trying to have something uniform (In which the OSDever must hack at his OS to get it to work if he's late in the game) why not have more useful documentation which anyone can implement at their liking?

Any legal issues with this or has it just not been done? If I knew atleast where to start I'd take a stab at trying to document some 2D acceleration drivers. Might be an interesting project.