Writing Drivers For Multiple Operating Systems?

Matt write: "I ran across this place while searching dmoz. KRF Tech has a piece of software called WinDriver that claims you can write hardware drivers once and compile for Linux, Windows 9x/NT/2000/CE, OS/2, Solaris AND VxWorks. My question: why isn't everyone and their mother using this software? It seems this software would make driver portability a thing of the past. They even have a free 30-day trial." The theory is cool, but how well does this work in practice?

Comments

Ask about UDI sometime...

[The Man]

on linux-kernel. UDI, for those who are unfamiliar, is an initiative by some hardware and proprietary software people to do write-once drivers for Unix. Like any such effort, it relies on an abstraction layer that interfaces the "real" OS-level driver layer with the driver components themselves.

The problem with this product, as with UDI, is that performance suffers. The linux people refuse to take part in UDI for a number of various good reasons, which can most simply be expressed as "the performance sucks rocks." See also a similar discussion based on a misunderstanding of ImageWorks new WAN code. Essentially, the concept of providing a common binary interface to multiple different kernels - be they different systems altogether or simply different, incompatible versions of the same system - is an old one, something of a Holy Grail to some people it seems.

The bottom line is, hardware vendors who refuse to open up the specs to their hardware are always looking for a way to provide as much "checkbox" operating system support as possible without actually doing any work or participating in the development community. There's an important technical downside as well, besides the poor performance these abstractions cause: if a vendor writes a poor winblows driver, then ports it to $favourite_os, what do you think this does for the stability of $favourite_os when the driver is loaded? That's right, it goes to hell. Microsoft has said for a long time that the stability problems their platform is known for are caused by third-party drivers. While I don't believe that's the whole story, they have a legitimate gripe here. If someone takes that same driver and loads it into Solaris, Linux, or vxWorks, they're going to suffer many of the same problems they would on winblows.

So no, this isn't as good as it sounds. Linux especially is rejecting such ideas from its mainline tree, but it's important that people also be aware of what their distribution vendors are shipping - it might be too tempting for one of them to say, look we can support winmodems but we'll have to add this proprietary cruftware patch to the kernel; it sucks but we'll be the first so let's do it. I'm wondering more and more whether Linus is regretting his binary-only module license exception.

License Dependancies...

[Christopher B. Brown]

The "cool idea" of the product is that it allows you to:

• Develop your device driver using their graphical Wizard (available in Windows only)
• And then use it for 30 days, unless you become a Registered User.

Note that the price of a WinDriver license runs somewhere between $1000 and $2000 (not 100% clear what the $1000 package is). Which means that if you want to use this to deploy a device driver, you get to pay out "a couple thousand bucks."

What is entirely unclear is what is the status of the resultant drivers. Is the code that is generated:

• Yours to do with as you like, including applying the GPL so that it could go into "official" kernels?
• Partially yours, and partially KRFTech's Driver Support Code, which you can't release?

  In such a case, the only way to use the results would be as a kernel module, due to the resultant license conflict...

• Partially KRFTech's, with a per-copy licensing fee?

I'm not "accusing" as the web site provides no indication one way or another. I'd find it surprising if the driver became "totally free," and that lack would put a big wrench in the "general interest" in the product.

I'll bet they sell some copies for organizations that plan to deploy Linux on embedded systems that are used internally; I suspect that the product is not of all that much "general interest."

As someone who has used this!

[Ex-NT-User]

I've used windriver at my work place. It's a neat idea but has a LOT of problems.

1st the good news:

1 YES it does allow you to write truelly crossplatform drivers. I've done this.
2. It's easy to use (a lot easier then learning kernel stuff)
3. It's very stable.

The BAD news:

1. It's SLOOOWWWW! This is because a driver written usiong this tool kit runs in USER space/mode. Which means there is a kernel switch penalty for every io operation.

2. It does NOT allow REALTIME IRQ handling. (Well it does but it makes you jump through hoops and you have to learn about KERNEL stuff for the OS you're writing tis for).

3. It's no good to you if you're looking to write a block device driver. It's only usefull if your writing drivers for weird custom hardware.

4. You need to redistibute their kernel-user mode driver module with your product. IE the kit DOES NOT generate a standalone driver.

4. Did I say it's slow?

If any one has specific questions Let me know.. I've used this product extensively.

-Ex-Nt-User

Worthless, undesirable.

[Andreas Bombe]

People, we had such stuff developed before and it was rightfully not used by Linux kernel. The only thing that got some discussion was a sort of standardized kernel API for drivers (called UDI, I think). The problem with such generalizations is that they hit performance and that they don't fit everywhere. The latter adds to the former, because some standard semantics have to be emulated in an ineffective manner (where there would have been simpler and aggressively optimized operations available natively).

That were just the problems of good frameworks. Now this KRFTech thing on the other hand... First it's not a real kernel driver development kit, it's an interface for user space drivers. This has more speed problems and big problems with interrupt handling: an IRQ stays asserted until the hardware is told to clear it, and only the driver knows how to do that (if the IRQ isn't cleared the system will infinitely reenter the IRQ handler). Now when the driver is in user space, there is a definite problem, since it can not handle the IRQ directly... So they probably do some heavy kludging to get around that.

Then, their so called "advantages":

• Simple - No operating system or kernel knowledge needed.
• Stable / Safe - Keeps unexperienced developers AWAY from the Linux kernel.

Advantages? Would you really want to use a driver on your Linux box that is written by someone without a clue of the Linux kernel? I know what they mean with keep unexp. developers away from kernel (they don't see the API), but since they access the hardware they have the same chances of causing big trouble as a real driver programmer. It's actually the opposite since it really invites clueless programmers to write drivers. The Visual Basic of driver programming.

There are even more problems. The drivers using this system require a non-free kernel module to work. The source of which won't be publically available, judging from the web page. Sure, the developers get a copy of the source so that they can modify it for different Linux versions (how generous - we may even choose ourselves on which Linux kernel we want to run this on). The problem is that the end user of the driver needs this module to run on her kernel, not only the developer. Compiled with the same compiler and options as the rest of the kernel.

Other things: does it support SMP, architectures other than x86, the latest developer kernel?

This stuff is not worth the bytes it is written on. Don't bother reporting on it in the future.

Uniform Driver Interface

[Deven]

Project UDI (Uniform Driver Interface) is approaching this write-once, run-anywhere driver implementation idea in a fairly comprehensive manner.

While it's not ready yet, the architecture is impressively clean and powerful. The same UDI driver code could potentially run (with only a recompile, no code changes) on a Windows system (e.g. Win95 or NT), a Unix system (e.g. Solaris or Linux), a small multitasking system without VM (e.g. Amiga), a small singletasking system (e.g. MS-DOS), or an intelligent I/O processor (e.g. I2O)... Each of these systems would need appropriate implementations of the UDI environment, but could run the same drivers. UDI drivers are written with very few assumptions about multitasking, memory protection, etc. You could even protect the OS from buggy drivers! (At a performance cost.)

As a case in point, SCO's next-generation Monterey operating system is slated to use UDI as its sole driver API...

Why UDI is a GOOD thing.

[Deven]

You seem to have a number of misconceptions...

No, a closed source driver is not better than nothing.

Tell that to the large number of people waiting for drivers that aren't forthcoming, who don't have the skills to write the driver themselves.

Closed source == binary == specific kernel version. People will load it for other versions anyway.

A driver version should not be tied to a kernel version in the first place. With a well-defined API (i.e. UDI), this sort of backward-compatibility and forward-compatibility will work and should be encouraged. Needing to rebuild every driver because you updated the kernel is a waste of time and effort, especially when the drivers need updates to match kernel changes.

Closed source == little review == it-compiles-so-ship-it attitude == lousy quality. Both cases lead to people complaining about Linux when it's a specific driver at fault which they almost certainly don't know about.

The Linux UDI environment could be implemented in such a way that the kernel and other drivers and programs are protected from buggy drivers. This is taken for granted in userspace with user programs, but everyone assumes that drivers have to be privileged and that a buggy driver can always crash the kernel. UDI drivers don't know or care if they're running in a protected environment. It might be slower, but it would make Linux more stable, not less! (It would also allow blame for buggy drivers to be placed appropriately.) Also, you would still have the ability to implement an Open Source driver, which would hopefully be of higher quality than the closed source driver, giving the best of both worlds.

Furthermore, a closed source driver will lead to pressure to not update the kernel because it would break closed source drivers == no improvements == obsolete code, code to handle historic cases, etc etc etc.

Quite the opposite, actually. UDI drivers would (finally) separate out policy decisions and leave them in the kernel, where they belong. More improvements could be made to the kernel's driver code, because the API remains unchanged and drivers need not be recoded for architectural changes. Also, there would be no reason not to update the kernel for non-driver changes, since the UDI drivers written for the old kernel would be forward-compatible with the new kernel supporting the same UDI specification. In fact, rewriting drivers using the UDI model would allow existing historic cruft to be discarded easily.

Hardware vendors who can't see the rational for open source now aren't going to suddenly see the light just because it's UDI instead of native. They will still be narrow minded and myopic. They will still imagine their competitors are so inept that they can't or won't reverse engineer the damned thing, even tho they do it themselves all the time.

So? We already have that problem, with companies that refuse to release anything but a Windows-specific binary-only closed-source driver, and no released specs. Handle it the same as now -- buy the products where the vendor "gets it" and shun the ones that don't. Consumers still have some power to affect these things, you know.

As for redundant drivers for different OSs, the problem is NOT getting vendors to write drivers, it's getting vendors to release specs so WE can write drivers. Think of it! They could release ONE spec and get drivers for free. What a concept!

You're in such a hurry to do their work for them? The Open Source community has so many spare development cycles that we should waste them on every variation in hardware instead of developing innovative new software? I've got a better idea -- let the hardware vendors shoulder the burden of basic support for their devices. If they want a high-quality driver, they should be smart enough to release the basic driver as Open Source (and release specs) so that they get bugfixes and enhancements for free. If they're myopic enough to keep the source closed, the market will tend to converge on the smarter companies who release the source because their hardware will work better. I'd rather see development cycles spent on Mozilla than subsidizing hardware vendors...

Backward and forward compatibility hinders development. You get a bloated slow kernel because it has to support all sorts of obsolete crap and try (and fail) to support unknown future capabilities. Worst aspect of "future" compatibility is that future drivers are constrained by previous thinking, meaning losing all advances since the forward compatibility was designed.

It only hinders development if poor API's were chosen to begin with. Look at the compatibility problems caused by IBM's shortsighted BIOS interface, just in the area of hard drives. (540 Meg limit, 2 Gig limit, 8.4 Gig limit, 32 Gig limit, etc.) It is very hard to design a good interface for device drivers that doesn't hinder future code with a bad API. Project UDI has spent years designing this API, and it shows. Why don't you try reading some of the introductory material about UDI? They really thought about this, and came up with a very powerful and flexible framework. (Jury's still out on performance.) Down the road, if UDI 1.0 doesn't meet the needs, a revision of the API could be done, which probably means dual compatibility for a long time. Such a thing wouldn't be done casually.

The ONLY advantage would be for prototyping drivers. Maybe someone could write a user mode driver with a generic kernel interface. Gawddd! Swapping in a user task to handle interrupts! What a mess.

UDI would be excellent for prototyping drivers (even if performance sucks), and good for keeping unstable drivers under control (if the environment is designed for it). Yes, userspace drivers would perform poorly compared to kernelspace drivers, but why not allow both modes? Untrusted drivers could be loaded into userspace and run slowly but safely. After they've proven themselves, the user/sysadmin could choose to allow the driver to run in kernelspace for performance. Best of both worlds. (This switching could potentially even be automated...)

One other thing: UDI represents the best hope for "fringe" operating systems (e.g. HURD) to get comprehensive driver support. A new OS only needs to implement a UDI environment, and all existing UDI drivers would work "for free". Wouldn't more competition between free OS's benefit everyone? Let's relieve alternative OS authors of the burden of constantly trying to achieve device driver parity with established OS's. Linux has been fighting that battle for years. Now that Linux is becoming one of those established OS's, Linux users are getting cavalier about support for non-Linux OS's. Should the "next Linux" have to duplicate all that effort? Entrenched Windows with its superior applications and driver support has always been a major barrier to entry for Linux. Sure, Linux is a better OS, and may "win" over Windows in the end. So when another OS comes out that's better than Linux, would it really be a good thing for that OS to have the same barrier that Linux has had to overcome?

Thoughts on the motivation for this ...

[The Code Hog]

Anyone who reads the Linux Kernel mailing list (or even scans the digests) is familiar with the nasty recurring battle over binary compatibility of Linux drivers from stable release to stable release. The Powers That Be in the Linux Kernel world are committed to not worrying about binary compatibility across releases for a variety of reasons. Some of these reasons are good, some smack of stubborness, but that's OK.

I've written drivers for cards under NT, Solaris & Irix. In some cases it was an in house designed cards across all three platforms; in others it was a quickie driver for a specific card on a specific platform. Drivers can be very persnickety creatures requiring *lots* of fine tuning. They can also be plain-vanilla simpletons with no thought for performance.

Solaris has a fairly nice abstract ddi/ddk layer, letting you abstract things like endianess out of your code. And my 2.5 drivers work without a hitch under 2.7.

Windows is insane, because of its compatibility heritage. There are *tons* of special cases and exceptions. After 2 drivers with the HAL layer I went out and bought a 3rd-party C++ library that abstracted most of Windows undergarments away from me (Vireo DriverWorks, which I recommend). There are new developments in the Windows world since that effort however. Luckily I am gone from that!

Irix was icky, mainly because SGI couldn't decide if they really wanted to support PCI or not. They sure didn't want to support PCI bridge chips. Eventualy we were able to get enough atches to the OS to get it to work but it wasn't thrilling. Pretty damn fast however.

With that as backround, I have to say that the 1 source compiling to many driver binaries will only work at all well for simple stuff. Things like inked-list DMA, card-to-card DMA, etc, are tricky beasts and are very OS sensitive.

And endianness persisit as an issue; Solaris lets you specify any arbitrary memory range to be an arbitrary endianess.

On the other hand, because of the conflagration over binary drivers across Linux versions, a toolkit like this that just targeted Linux would be very nice; it would let companies write closed source drivers for Linux and not get hammered with each new stable tree. And sometimes closed source is an economic necessity for companies -- they may have signifigant IP tied up in that driver.

New product

[ceswiedler]

NEW from BRF Technologies...

Our new WinCoder software makes coding as easy as speaking! The WinCoder package comes with a special "development microphone" which connects to your PC through your sound card. Simply speak clearly into the microphone and request your program.

For example:

"Computer, make me a Linux device driver for my PCI BleeduxEdge video card!"

"I want a program which automatically spies on my ex-wife!"

"Show me eight thousand different pictures of Natalie Portman pouring grits down her pants!"

...And as easy as that, you've got a program! No more typing! No more reference manuals! No more staying up all night trying to finish a project! We guarantee massive throughput--less than thirty words per program! Ports to any OS--Unix, Windows, Macs, and even PalmPilots!

How it works: your program request is digitized and sent to a special warped-space cage where an infinite numbers of moneys type at an infinite number of computers. A special program-matching application identifies the monkeycode which most closely matches your request, and returns that program to you. The entire process takes an infinitely small amount of time!

Order yours today!