Slashdot Mirror
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?
Of course, this cross platform thing would be useful for making sure there is support for as many possible platforms ASAP, then optimised platform specific ports could come at a later date...
Yes, where "later date" == "never". You're ignoring the lessons of history. If it's "good enough," it'll stick around forever and its vastly superior replacement will never see the light of day. It's happened way too many times. How else do you explain people willingly buying a 16-bit operating system for a 32-bit CPU that can't compete with its 64-bit competitors that have been around for five years? Good enough indeed.
I like the line about "safe and stable... keeps inexperienced developers out of the Linux kernel"
Yeah right. Device drivers for Linux and other Unixes aren't that difficult to write, and besides who would let an inexperienced programmer mess with a device driver anyway? You still have to understand basic concepts like I/O ranges, interrupt handlers, DMA, etc., so really other than a time savings when porting from Windows to Linux (or other) this doesn't get you anything at all.
The only way they could implement this the way they claim -- with most of the driver sitting in user space making calls to a loadable module -- is for the module to be bloated and generic. The userspace "driver" then calls the LKM, with ioctls or some other mechanism, to get the real work done. Sounds like a great deal of indirection which would probably hurt performance.
Getting cross-platform compatibility for device drivers isn't difficult as long as you exclude Windows from the mix. I've written numerous device drivers for various hardware, and had to port them from old SVR3 to UnixWare and Linux. In each case the kernel calls are different, the methods have different parameters etc, but basically in most cases it's similar enough that you could almost write a Perl script to convert from one to the other. Obviously this isn't true of Windows, so I guess if you're really desperate to get a driver for Windows and you only know Unix this might fit the bill. And of course your "driver" won't work at all if they you don't install their module, and if they choose to not support or drop support for a particular OS you're up the creek.
My advice... If you don't know how to port your driver to a different OS, hire a contractor who does and keep the source code when they're done.
No, a closed source driver is not better than nothing. Closed source == binary == specific kernel version. People will load it for other versions anyway. 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.
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.
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.
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!
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.
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.
--
Infuriate left and right
----
- Drivers may become available that wouldn't otherwise be available. (Even a closed-source driver is better than nothing.)
- Hardware manufacturers would have some incentive to release driver source, since only source-level compatibility is guaranteed with UDI.
- Linux, FreeBSD and other free operating systems wouldn't have to waste time rewriting drivers already implemented, if they all support UDI -- duplication of effort isn't helpful.
- UDI drivers are cleanly separated from policy decisions about operating system implementation; changes to the core OS architecture won't require rewriting UDI drivers.
- Since UDI drivers would be backward-compatible and forward-compatible across all UDI-supporting versions of the Linux kernel, there would be no need to rebuild drivers when rebuilding the kernel, and it would be simple (and easier to maintain) to distribute each UDI driver as a separate package rather than including millions of lines of code in the Linux kernel for drivers, when any given user needs only a few of them.
- The Linux kernel could be designed to allow memory protection and fault-tolerance of UDI drivers, enhancing system stability at a (further) performance cost. (I'd rather have an experimental driver run slowly than crash my system!)
- If the performance is that bad, the existing Linux device driver API could be used for the drivers where performance matters. (Besides, some talented hacker may find a solution to the performance problem.)
Would supporting UDI in the mainline Linux kernel really be such a bad thing?Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
The idea of writing a universal driver interface is doomed from the get-go, since the kernels of operating systems differ so severely in their implementation and usage of drivers, that major concessions in the speed and robustness would be made to implement universal drivers.
:)
The best solution I could see is standardizing the hardware, so only one driver would have to be written for kind of each device.
So, for example, you could have the Universal Sound Card Interface, with 3D Sound and MP3 Decoding Extensions (to satiate Creative Labs, for example). The "Sound Card" would have a standard driver, and the extensions would be dynamic pieces of that main driver. Video Cards, Network Cards, SCSI Cards, and any other hardware that's lived out its innovative life-cycle and is basically using the same design from model-to-model could have Universal Drivers written for them as well.
The only case where this would be a problem woud be in hardware that's constantly changing its hardware interface and is always implementing new features. The Universal Driver would be a nuisance and a slowdown for any hardware that wants to add a new feature, since some council would have to OK adding this new feature to the next version of the Universal Standard Interface. (I'm mainly thinking of 3D Accelerators here, since most hardware doesn't really change that much.)
It could be possible to allow anyone to write any extension they want for any interface, allowing them to add innovate new features while still providing a standardized base.
And, of course, if that isn't good enough for them, they could just write their own drivers for their own proprietary interface for every platform they intend to support, like they do now!
It seems like it could work if hardware vendors cared enough about the "fringe" operating systems to get along with eachother.
---
Epitaph
However (and herein lies the rub) would that simply decrease the pressure to produce high-performance full-function drivers? I just don't know the culture of the Linux driver development sector well enough to judge. Worse, would it pread out and dilute the existing driver development talent, which currently focusses in depth on fewer 'supported' driver and projects.
Will we be dooming ourselves to a sea o' crappola in the interest of 'just get it done' ? [How many Win install are done every second because the end user wants a out-of-box experience, even if they know it's a crappy one? Will we fall into that same trap?] Will this make Linux look bad?
Factors to consider:
a) Many users are not satisfied with the rate at which quality divers are being written at present
b) Most users won't pitch in and write drivers. They just whine and complain. They should each buy a developer a keg for doing yeoman's work (Of course, then we'd never get any drivers written)
c) While many programmers specialize in drivers and find it very rewarding, others will seek projects that are more 'pressing in the sense of providing 'new', rather than 'improved' functionality
d) Crappy drivers can be a good starting place for respectable drivers.
e) Linux users will tend to buy more disparate hardware if they know they can at least get it to run (vaguely). Now they quickly learn to limit themselves to the supported devices (and hence are more likely to limit themselves to the *well* supported devices)
[1] Grenouille, IM and Crapaud, LS "Remarkable Surges in beta endorphin levels in Rana pipiens during programmed exercise" J. Bestial. Phys. 17:245-7 (1998)
__________
If you can go to bed, knowing you did a valuable thing today, you're very lucky. If you can't... it's not bedtime
So far I can test for NT, Win9X, OS-2, and a few of the Linuxes (2.0X kernels though).
I think my main test will be for a TWAIN scanner I bought back in '94, because I have the Win source code for both TWAIN21 and the scanner, but I am wondering if this is a good test or not, whether I should get a set of 2.2X kernels first, or what.
Just an opinion here, but if a person started with a good set of base class libraries for each platform, then building the common interfaces into a cross-platform driver and testing it shouldn't be too terribly difficult. Am I missing anything in my thoughts about all of this?
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
I'm no kernel hacker, but I guess this has a chance of a snowball in hell to get adapted by the kernel folks.
First, the idea seems old, look at the UDI project.
Looks even cleaner IMO.
And now watch the opinion of several high grade kernel hackers about it.
Two citations:
Dave Miller: "No thanks, IMHO OS neutral driver interfaces are a nice idea but they can only lead to mediocrity. (Yes I have read and understand how your stuff works, the problem will still be there)."
Alan Cox "Not sure why anyone thinks this is Linux relevant 8) - other than it will help to make our drivers even faster than the competition if they adopt it. Have a read, but keep a bucket handy". And after smashing the idea of OS independant drivers a bit more, he really gets funny: "So what are you going to do with it. Joysticks?"
On a quick glance, this thing has even more facts going against it's usage:
The worst:
-It seems to demand applications (not only drivers) to link special headers in order to use their infrastructure.
- It's name (WinDriver)
- This sentence on their webpage:
"Use the powerful graphical Wizard (available in Windows only), to create your driver source code. The Wizard will automatically generate make files for both Linux and Windows."
It doesn't appear that this is intended for writing the ultimate/best device driver. It's probably intended for people who just want to have a simple driver that works for their device.
Almost like a temporary solution until someone writes a "real" driver.
The Uniform Driver Initiative has been working on this problem for a while. Their homepage is here:http://www.projectudi.org/
Here's a brief overview of the problems i see with this:
- Loss of speed because it's not in the kernel
- Adding another interface to the kernel
- Possible security holes might be added this way
Of course, it would be nice to be able to just grab the DLL for the latest hardware and use it on both the Windows and Linux side. One has to wonder, though, how well this works on other platforms (ie Alpha, Sparc, and PPC).Nathan's blog
One at a time.
Let me start off by saying I don't have any experience writing drivers. But, my guess would be that this process isn't as good for writing high performance drivers that a lot of manufacturers require. For video cards, the drivers dramatically affect performance. Frame rates often have double digit improvements from early beta drivers to more mature versions.
Admittedly, it might be good to flesh out quick support for other operating systems, but the performance most likely wouldn't be there. Anyway, that'd be my guess. Besides, do we really want hardware manufacturers putting out cheap/quick drivers for Linux/Solaris/etc. and calling it support (just so they can put more text on their boxes)?
This looks like a Linux version of some software that is available for NT. It isn't a kit to write universal device drivers, it's a Linux device driver that is an agent for user-mode applications, allowing them access to kernel-mode memory addresses and I/O ports. This lets you access I/O boards from an application without having to write a driver.
Mea navis aericumbens anguillis abundat
See my previous post for a long response to another poster. I'll only address new points below...
This, I believe, may be only a chimera; there are enough differences between the mechanisms that are used to protect driver and kernel data structures from interrupt service routines and peer-processor access in the various OSs that it may not even be possible to create a set of UDI drivers, much less port them across major kernel architecture change.
Most such policy decisions (uniprocessor vs. multiprocessor, singletasking vs. multitasking, privileged vs. userspace, synchronous vs. asychronous I/O, VM or not, protected memory or not, etc.) are entirely contained within the UDI environment implementation on the OS side, and unknown to the UDI driver itself. In fact, the UDI driver code can be simpler, because it doesn't deal with interrupt masks, task switching, synchronization, etc. (Since the environment has to deal with these issues, the environment implementation is probably harder, but it only has to be done once for all drivers on that OS.)
Since some devices MUST BE present in the kernel to access a boot device (and console), there is no way to prevent rebuilding drivers into a kernel. The current system of modular drivers already permits non-boot drivers to be excluded from the kernel image, and these modules can be distributed as separate packages. BTW, I just ran a line count on 2.2.5; there is a total of 1005095 lines of source code.
While it makes the most sense for UDI drivers to normally be loaded dynamically, there's no reason some bootstrap drivers couldn't be statically linked with the kernel. After booting, those drivers could continue to operate, or possibly be replaced with dynamically-loaded (possibly newer) versions.
In my Linux 2.2.12 tree (generic Red Hat 6.1, I think), "wc -l `find . -name '*.[ch]' -print`" gives me 1642672 lines. Most of this is device drivers: 1117142 lines, or 68% of the total. Surely the kernel would be more manageable if this mass of code wasn't so tightly coupled with kernel internals?
The performance will be that bad, so the existing sort-of APIs will be used and all that will have happened is a lot of unused work creating the code to implement and support the APIs.
I agree that the jury is still out, when it comes to UDI performance. They've made efforts to keep it high-performance, but it's unproven. Even if the performance is poor, there are good reasons to support UDI.
If the Linux, bsd, etc. communities had been the driving aganecy for UDI, there's a good chance that the result would be a benefit to both users and device manufacturers. Since the current initiative is by M$ and the vendors that want to dump their M$-Windows drivers on Linux, bsd, etc., then YES it would be a REALLY, REALLY bad thing to implement UDI in Linux.
Why aren't the Linux/BSD communities driving UDI? UDI can be good for everyone but Microsoft. Project UDI is not a Microsoft initiative; they're not even a participant! (They also have the most to lose, as the most entrenched OS vendor.) The history goes back years (1993, maybe?) to a multivendor effort to create common drivers for UNIX systems. Major participants include Sun, HP, SCO, Intel, Compaq, IBM and others. SCO and IBM are putting UDI support in AIX, Unixware and Monterey. (For Monterey, I'm told it will be the only API for device drivers.)
Project UDI has an (outdated) HTML presentation that has some overview information to help give you a broad sense of the architecture -- it's well worth reading.
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Well, I was gonna flame this as being "Yet Another Rapid Application Development Platform That Isn't," but, after looking over their FAQ, this looks as tho it might be genuine.
:P Yer gonna cut and paste it anyways, so, why not? :P
:P
It's basically a framework that lets you write simple IO, interrupt handlers, etc, quickly, to test your card, and then write 'real' code to do the hard work.
So, it's cutting and pasting the reference driver, with a wizard.
I will say, tho, that the cross-platform aspect only makes a minimum of sense to me. If the critical aspects have to be hand written anyways (and they do) then all the CP does is let you quickly write "does it respond correctly to bit X" kinda frameworks.
Might be cool for high-speed serial devices.. I wonder if USB support could be worked out with this? Hrrrrmm..
I'll never know, because it runs under windows.
--
blue
i browse at -1 because they're funnier than you are.
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.
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:
In such a case, the only way to use the results would be as a kernel module, due to the resultant license conflict...
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."
If you're not part of the solution, you're part of the precipitate.
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
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.
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...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
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?
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
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.
-- "Vote Democrat. Because the current crop of conservatives are just bugnut crazy."
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!