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?
and I've written a lot of c-code, c++, ada,
Unlucky, I also had to write ADA. That's why I now work at Burger King.
http://roadrunner.swansea.linux.org.uk/i2o.shtml http://www.i2osig.org http://www.simon-shapiro.org/drivers.html http://www.wrs.com/products/html/intro_ixworks.htm l
Because most of these high level driver kits don't really allow you to write a real device driver. There have been several of these over the years and typically they supply a kernel mode "Generic" device driver that speaks to their own API (a DLL or SO). The customer writes a user level application against their API that talks to their "Generic" device driver. This is a cool solution for a quick and dirty driver, but it falls down in the real world in several ways. These solutions are a least common denominator solutions. You can only access hardware that they have already provided for and you can only touch the hardware in the ways that they have already provided for in their API. Second because they try to support as much hardware and API functionality as possible it's a heavy weight solution. You are using a driver that will typically have many times more code in it than you will ever actually use. Third some of the solutions like this that I've evaluated only allow a single application to access the driver. So it's an ok solution if you want to hardware enable a specific application but not workable if you are a hardware vendor trying to create a shippable driver. Fourth, most of these are not open source and if you want your driver to end up shipping with the kernel it's not going to happen if it's not open source...
Free Software works when lots of hobbyists have the necessary skills and equipment to develop a particular system. But only a few people understand signal processing, trellis coding, and characteristics of noise sources on our antiquated telephone network and can lay hands on line simulators, and almost all of them work for modem vendors under nondisclosure. The 2400bps protocol was probably the last one J.Random Hacker could implement adequately.
it seems they are already in a test phase. you can read their two relevant press releases here and here.
"Just do me a favor, ok? Don't breed!" -- Adam Carolla, Loveline
I see, so in other words free software needs to
compromise in order to fit with your view.
Bullshit Jack
First off if you want proprietary Unix, "sarcasm"
I'm sure you can find someone to sell it to you"/sarcasm".
Second, if you you have a need for a peice of hardware
Thats not supported under Linux and you insist on using Linux,
you have _extremely_poor_judgement_.
Third, the whole open/proprietary thing is like a
stare down contest, you blink, you lose
Also where is it written that it's anybodies god given right to use _any_ of this stuff?
You talk about supporting companies that "get it",
what _you_ don't seem to get is is that
by compromising on issues like this you get the worst outcome of each method.
You're in such a hurry to do their work for them?
What do you give a shit if somebody wants to spend
some of their own time writing a driver?
You complain its takes developers away from improving existing software.
I don't know about the planet you live on, but where I live free software improves every day.
Take a look at drivers for emu10k1 chipset soundcards as an example.
Then look at a feature comparison.
Creative says a release quality proprietary driver is due out "summer 2000".
I requested a feature on the open driver
and it was implemented in less than two weeks.
Let's see a vendor do _that_
While yer at it score a _recent_ linux
distribution that supports that scanner
and compare the performance in that with the
driver you get using WinDriver
Those users have paid Microsoft for a product. That product does not measure up to the promises that are made, and the users are not given the opportunity to correct the problems themselves. In the Linux world, you don't pay the developers, no promises are made about the software, and if there's something you want done you are free to do it yourself. If that means a fork, then it means a fork. At least you have a choice.
It has nothing to do with being abusive toward users. If all the users are doing is taking from the community without contributing (since most of them can't anyway), then I fail to see why someone who has invested his own time and effort into a piece of software that represents his view of correctness should be required to support these users by either working on or accepting patches that conflict with his own ideas. If you want something with UDI, you are free by virtue of the GPL to put out Fredix, or to pay SCO for it. If you don't like these options, tough. You have in the Free Software community a large number of people willing to give you something for nothing. If that something is of no value to you, then you've still come out ok. I fail to see the parallel with Microsoft; you pay them $500 for an OS and a web server that they promise will work, and then it doesn't work. Well, in that case you're out $500. You pay Linus nothing for Linux, which is delivered to you as-is; if it doesn't work, so what? Where along the line did you acquire the right to insist that he add UDI (or anything else) to his operating system for your benefit?
The way I see it, Linux belongs to Linus. It is his OS; he has generously allowed you to have, use, modify, and redistribute the fruits of his efforts, as have all the other hundreds of major contributors. If it's useful to you, great. But it still belongs to them, and if they don't want your changes in it, that's their right. They owe you nothing.
I do not care how much or how little market share Linux has. Whether someone else uses it means nothing to me; I can continue to use it as I please even if every single other person stops using it. Welcome to Free software.
More users result in more developers. More developers result in more support. More support results in more things that you want for your OS.
I don't really think this is true any more. The type of new users Linux is attracting today doesn't know a stack frame from a superblock, and doesn't intend to learn. These people aren't kernel hackers. They aren't applications developers. They aren't even helpful bug-report-submitting users who understand what quality software is all about and are proud to help it along in some small way. In other words, unlike previous Linux adopters, they take, take, take, and give nothing back. From a developer's point of view, these people do nothing to help the process of making a great system; all they do is clutter up mailing lists with useless bug reports and inane feature requests. New projects? Yeah, right. Patches? Don't hold your breath.
Even if these people were useful developers, they wouldn't be able to help much with the issue at hand, device support. Today's support for devices is limited by documentation, not coders. Help is always appreciated of course, but one more programmer's manual would make a lot more difference than one more developer.
You can ... sign mass petitions to get a native driver.
I don't do that. I vote with my currency units. No open source? No specs? No money, then. Petitions are for whiners.
To be more precise, the Linux purists are afraid that Linux users will be satisfied with the UDI drivers and won't be as eager to join mass driver movements.
These people were satisfied with windows six months ago!!! Of course they'll be satisfied with UDI drivers; they'd be satisfied with three tons of steaming shit and a more comfortable chair. The nice thing about Linux is that the people who make it won't be satisfied with UDI drivers. But these "mass driver movements" you mention actually have very little to do with getting native drivers written. In fact, what usually ends up happening is that some competitor gets wise and mails a manual to some hacker who then writes a driver. The hundreds of petition signers don't know how to write drivers and in most cases are probably just following the Slashdot crowd anyway ("what's the petition for? d00d, it's a driver for the Mumblebazco Vapourware 5200!!! The WHAT? Oh well, I'll sign anyway.")
If you don't want users to be complacent with UDI drivers, then tell them so.
Right. "That driver offers 30% suboptimal performance!" "So? It plays quake."
But don't take away the choice just because you're too lazy to do it.
But you see, we don't write this code for others. We write it for ourselves, and share it with others because we feel it's the right thing to do. We don't have any responsibility to the users whatsoever. For the 99.8% of us who write Free Software and don't get paid for it, the fact that some user wants UDI means nothing. The simple fact is that the people who generously volunteer their time and skills to work on these projects have earned the right to decide what goes in and what does not. And UDI will not. Not because we're too lazy to do it (not that it would matter even if we were; we owe you nothing), but because we don't think it's a good idea. If you want UDI, you're free to write it yourself and maintain your own tree. Did Linus wait 10 years for Tanenbaum to open-source Minix? Did RMS sit around and wait for all the proprietary software vendors to collapse? Of course not. They rolled up their sleeves and got to work. Unlike them, you aren't forced to be a pioneer; you'll find a ready and willing crowd of people to test and maybe even contribute to your project. You can even get free project hosting if you want it. In fact, all you need to provide are your skills and time.
There are only two ways to ensure you get what you want: pay someone for it, or do it yourself. Berating volunteers for being "too lazy" to give you what you want, against their own better judgment, is rude and selfish. Stop and think for a moment; if you felt UDI were a bad idea poorly implemented, would you want it in a world-famous product that bears your name?
Thanks for making this point so succinctly. To answer the rhetorical question, essentially none. :)
By significantly reducing the amount of work needed to produce something that can realistically be called "Linux support." Producing a fully native Linux driver requires significantly more work and knowledge than taking the UDI boilerplate code and throwing in the microcode for your device's ASIC. Producing a UDI driver (or letting someone else do so for their own proprietary OS) and then saying look, it works with Linux is much easier. It's a quick and easy way to add the increasingly important Linux checkbox to their marketing gloss without giving up any of their docs or paying someone to write a driver.
But maybe we're just splitting hairs anyway. The simple facts are that, politics and licensing aside, UDI will not be a part of mainline Linux anytime soon, if ever, and that this decision has been made for technical reasons, rightly or wrongly. We can argue the nontechnical side of things, but the people who matter don't care in the slightest.
I'm not up on the technical details, SciTech being non-free software, but AFAIR they have an OS-specific driver which runs a small virtual machine, mapping system calls in a theoretical 'nice' OS to system calls on the current OS, and then a binary 'driver' which is loaded, and interacts.
May sound questionable (performance wise), but their drivers work in OS/2 and Windows at least (I remember reading that they also had a Linux version for X displays), and I've heard good things about both stability and performance.
--Matthew
Based on the way they've explained it, you don't really have to get your own copy to understand how it would have to work. There are only so many ways to code a driver. So those of us who do have experience writing drivers -- and a few of us have already posted -- do have something to offer the discussion, thank you very much.
>The next question goes that since winmodems suck and are slow, and
>opensource development is supposed to yield superior results to
>proprietary schemes, why doesn't anyone bother to show up the winmodem
>manufacturers by making a driver for the modem that yields better
>performance while using less CPU cylcles?
Maybe because most people running Linux or a BSD don't own a Winmodem, and have no intention of buying one?
Take the detonator drivers on the Riva 128 and TNT for example. Performance increased a good 35% (brought a 128 close to a Voodoo2 for QuakeII), just by changing drivers. You rarely see that kind of optimization in Open source stuff.
Thats because its usually done right to begin with. Any company can push a crappy driver out the door and then release what they should have in the first place and claim a 35% increase.
With open source drivers this simply doesn't happen. You put out crap, someone goes over the source and you get a whole lot of feedback that goes a lot like "Dude, your code sucks." Now, once in a while one of those flame mails will come with helpful patches, but the flames are a form of QA on open source drivers, or anything for that matter.
As I understand it (I'm a Mac person myself) WinModems shift a lot of the work of the modem off into software that runs on the CPU. This is a hell of a lot more work b/c you're not just sending commands to a black box - you have to rewrite half of the box to begin with.
Additionally, that's a fairly inelegant way of doing that right now (particularly given how many cycles it eats up) and so I don't think anyone really wants to support them.
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
It is highly doubtful that a driver designed for an os like Windows could work on an OS like linux or the HURD.
If the world could agree on one microkernel and then put a uniform driver layer.... Then something like this would be more feasible. After the driver layer the OS could look-like anything you want.
Since the world doesn't work this way I have many doubts about how well something like this would work. I don't even think it can work but then I had doubts about VMWare too!
If it's true-- great. If not... Oh well it looks like April fools day is a month long...
Leimy
Actually the sad thing is most of the posts are from those who have experience in some side or another. Maybe they don't have enough experience or just want to speculate on why they think it isn't possible.
If it works despite all of this speculation then you can see how groundbreaking a product this is.
From what I have been reading so far it does work but isn't for high performance settings(like everyday use for me). The question isn't does it exist or does it work but WHY?
Oh yeah and I write TONS of code (C++, LISP, Scheme, Python, C, ASM, PHP, Java, BASIC, COBOL and whatever else I want to learn) so don't blindly state what you obviously don't know.
I have no respect for Anonymous Cowards!!!!
Leimy
If they don't handle anything it will create very ineffective results. Don't have to handle synchronization? Implementation on SMP then means that the Big Driver Lock must be held whenever the driver code is executing on one CPU, whether it needs it or not. Goodbye scalability.
Surely the kernel would be more manageable if this mass of code wasn't so tightly coupled with kernel internals?
Only if you don't care about enhancing the Linux kernel. An API set in stone means that this has to be supported as written, no matter if you have to work around five corners to support it because it doesn't fit your kernel.
Linux sometimes breaks driver interfaces and adds different ones during the development kernel cycle. Do they do it to annoy driver writers? No, they do it because the new interface is cleaner, more effective or fits better another updated part of the kernel. UDI means at least for hardware drivers stopping development and watch performance going down the drain. Or it means designing the kernel to fit UDI, which certainly won't happen.
Why aren't the Linux/BSD communities driving UDI? UDI can be good for everyone but Microsoft.
UDI is mainly good for hardware vendors who don't want to release driver sources or specs. Why should the free software community support that? If the driver specs are available then drivers can be developed and maintained for every OS, no problem.
How much hardware with available specs is unsupported?
But modules have a higher memory footprint on running kernels. Statically compiled, the functions of all drivers follow each other one after the other. Modules on the other hand are loaded into full memory pages (4kB on x86) and some of the memory in the last page may be left unused.
Point by point:
Once this model is accepted, manufacturers will have an incentive to release only the current M$-
Windows drivers. No driver (and lost device sales) are better than the M$-Windows drivers.
Possibly true, but is "some" incentive enough?
Duplication of effort may be helpful; when I worked on AIX for the PS/2 we found hardware
problems that didn't show up in M$-Windows, although they did, later, when OS/2 came out.
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.
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.
Although driver-private memory could be assigned to different contexts (at a huge cost in wasted
memory and some significant CPU overhead switching between the various contexts), there are common
data structures that would have to be accessed through an API and, presumably, another kernel-
common context. This would create much more code to be maintained and more code does not guarantee
additional stability, although it nearly always has a performance hit.
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.
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.
I have to disagree. Open source doesn't seem to be helping things like the Linux NTFS driver, which, If I understand it correctly, is about to be dropped because its maintainer no longer ports it to newer kernel versions.
There's nothing wrong with having a stable driver interface, even if you have the driver source. Source code is useless if nobody is willing and able to do the work necessary to keep it compatible with new kernels.
I've often wondered why there can't be an abstract language for creating device drivers and possibly simple Internet protocols. I admit to never having written a device driver but I've read some books on it and worked with the electronics side of things and I never understood how device drivers are different from a low level communications protocol? I've written abstract bot lang's before that worked sort of on the theory of input's and output's that can either trigger an auto response or create a hook for more complex software layers. I'd think you'd could at least have it provide an API for low level communications that'd be portable across platforms. Anyone know?
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
You're in such a hurry to do their work for them? The Open Source community has so
/. as though it's some sort of must-have is silly. :P
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
Just like everything else in the Open Source world, if the UDI kids make a better product, make enough drivers that are better than the native ones to make a difference, and etc, then the distros will start packaging UDI, and UDI will win.
It prolly won't happen. I think UDI will slip into a few places here and there, but, really, I have a hard time believing that any abstract interface can keep pace with the development of even one, much less many, operating systems. What happens to any sort of UDI filesystem when the VFS interface changes? (Not that such a thing exists, it's just what's on the top of my head.) What would happen if Linux, OBSD, and AIX all changed driver layers over a few months?
Also, it's easy to make a corrolary (someone get me a dictionary!) between UDI and Java. Java is the same sort of thing, an abstract interface to operating-system level operations. Wanna tell me how well java code works across OSes? How about how well it survives updates in the core interpreter? Saying that any abstraction system works just because it's an abstraction ignores the pretty much inevitable force of change - the abstraction itself is as much of a moving target as the operating systems on which it works. Change happens. Flexibility, in both the interpreter and the interpreted code, is what makes things good. Usually, it also makes things sloooooooooooooow. Slow device drivers for fast devices is a sucky idea.
Anyways, like I said before I started rambling, the users will prove it or sink it. Arguing about it on
--
blue
i browse at -1 because they're funnier than you are.
Open source doesn't seem to be helping things like the Linux NTFS driver, which, If I understand it correctly, is about to be dropped
Anybody who wants to can fix it. Seems nobody step up to the task, so nobody (able) are interested in a linux ntfs driver. Dropping it is fine under such circumstances. Oh, you want ntfs after all? Write it then...
but no one can take the time to figure out the modems that seem to appear in almost every shipping PC?
You're living in a bad part of the world. I don't see much winmodems around here. Too many gullible buyers where you live?
There is some overhead during module loading, but once the module is loaded, there really should be no performance loss/gain over a regular compiled driver statically linked into the kernel.
There is a small gain for statically linked drivers on pentium processors. (I don't know about the non-intel ones)
Linux use paged memory, so the CPU's MMU have to look up page tables for every address used. This takes time, so obviously there's a cache for this sort of thing, called TLB (Translation lookaside buffer). The TLB caches a few page adresses, anf get a time-consuming miss whenever some address not in the TLB is accessed.
Pages are usually of size 4k, so there is a lot of misses when working with something substantially bigger. Now, the pentium has a trick, a 4M page used to hold the statically linked kernel. This means kernel code can jump all over the place without getting any TLB miss. Module code however is loaded into ordinary 4k pages, and stand a much higher chance of TLB misses. Just like ordinary programs. So there's a small win for statically linked kernel drivers.
Drivers may become available that wouldn't otherwise be available. (Even a closed-source driver is better than nothing.)
Not that much of a need anymore. Linux supports all kinds of intersting hardware, be a _little_ careful when buying and you'll be fine.
<I>Linux, FreeBSD and other free operating systems wouldn't have to waste time rewriting drivers already implemented, if they all support UDI</I>
Too bad the UDI spec isn't good enough. Several kernel experts says it won't perform well, particularly not on SMP.
<I>I'd rather have an experimental driver run slowly than crash my system!</I>
I rather have some pressure on developers to get it right. Most of linux works wery well thanks to this.
Many corporates just can't see things that way. "If we release our specs to everyone," say the typical Joe Corpobutt, "our concurrent will know how to do the same hardware, and, as they've better engineers than we have, they'll soon sell better and cheapier version of our products! No way!"
Too bad for Joe Corpbutt then - he's lost the linux market already. This is not a problem, as there is hardware enough for us. More is fine, but we don't desperately *need* it anymore.
And the argument is flawed, a spec for what the sw should do to make the hw work doesn't provide enough info for reverse-engineering the hardware itself. Put some custom chips on the card that nobody else can get, and they are lost.
Maybe for linux. The driver model for NT has
remained stable since the earliest versions. Of
NT4-era drivers can't take advantage of newer
features in Windows 2000 like plug-and-play but
they still work.
Good idea. Consider it added.
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
Darn, missed the preview button again. I meant "TWAIN32".
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
I would like something along the lines of what is being discussed on linux-kernel now.
It's not targeted at binary only, but obfuscated source would work.
The kernel should contain some kind of generic makefiles and driver source skeleton. Then the driver writers could use this as a kind of source level infrastrucure to automatically compile and insert kernel modules. Any problems emerging cause the user doesn't install a compiler should be targeted by the distribution makers.
Hmm, maybe you never looked for drivers? Take a look at http://www.multiwave.com/support/cw_pcilu_support. htm - a driver for LT Winmodem's from the manufacturer for linux...
-- If I were a fish, I'd be wet
Actually, a company called Software Technology Group is working on the UDI implementation for both Linux x86 and Linux PowerPC.
Hockey - Canada's gift to the world
Hockey - Canada's gift to the world
I've been wondering how long it would take before somebody advertised their products in a Slashdot comment. It's distressing so see such an ad right in an article. But perhaps it's not surprising considering the terrible anti-gravity article posted a couple weeks ago. Seems that Slashdot's screening process is only about 90% crap-proof. (A heck of a lot better than most other news sources, though.) At least the discussion in response was worthwhile.
If I see one more banner ad, piece of spam, or e-commerce propoganda today I'm gonna unplug my computer (and burn my copy of Wired). Grrr.
Better no driver than one that requires a closed source kernel module to run. The _only_ thing that this will do is to distract hardware manufacturers from doing the right thing (tm).
As for the technical specifics, none of us are in any position to comment on the technicalities, as we haven't been made privy to this information.
NO MORE BINARY-ONLY KERNEL MODULES!
The thing is that those modems that you see today, well they aren't modems at all!
Right, they're not. So don't think of them as modems. As one guy said (sorry, forgot who), think of them as interfaces to the phone line, or something. You see, with the proper drivers, your winmodem could fully access the line, generating tones, voices, etc. So they'd be pretty useful as other things, in addition to modems, if only we had the specs.
The drivers do all the work - a lot of code that isn't easy to write. And its likely different for each of the hundreds of kinds of modems.
Once again, correct, the drivers would be difficult to write, but to clarify, the main driver would probably only have to be written once - that would be the signal processor thingy. And that's the hard part. After that, yes, it would be difficult to find out how to access the capabilities of each "modem," but I don't think you'd have to rewrite the signal processor each time.
And futhermore they suck, because they eat up processor time.
This I really won't buy. Sure, they use processor time, but these days they sure won't eat it up. We've had these things since the early Pentiums, perhaps even earlier. Seeing how fast computers are these days, I don't see how this claim can hold up. "Oh yeah, I was trying to browse the web, but my 600 mhz Athlon was too bogged down by my winmodem." Pfft.
Of course, I could be wrong about all of this, so feel free to prove so. Also, don't think that I'm saying we should all have WinModems. I'm just saying they wouldn't be as bad, if only some specs were released for the small amount of hardware in them.
OK, so winmodems have a few common bus interface chipsets. What I'm unsure of is what sits between the bus interface chips and the telco land lines. If the step xformers, DACs, etc, are different for each type of card (which I believe they are, to prevent copyright/patent infringement if for no other reason) then we are right back where we started. Any ideas about this?
Michael Gentili
- He's just some guy, you know?
So, fine, why is it such a big deal to write a driver for these things, and why aren't there any out there?
Well, when you get right down to it, a driver is simply passive glue logic that allows the kernel to talk to a device. Often, fully functional drivers can be written for the simpler devices with a few hundred lines of code or less (This does not include the optimizations or kludges that are often required to get around quirky hardware or make it run at acceptable speeds). Most of the work required is in figuring out how to talk to a specific device.
But in the case of the winmodems, there's nothing much to talk to at all. The drivers for these things shouldn't even really be called drivers. They are fully functional hardware emulation routines that take the place of the microprocessors, UARTs, and EPROM chips that usually go into making up a modem.
Now, as an open source developer, I have no problem spending a liesurly Sunday afternoon or two banging away at some device that I want to work on my system. But this undertaking would amount to designing and implementing a fully functional hardware emulator. This requires a dedicated team, such as the one working on WINE (which, granted, is not a hardware emulator).
OK, so what, we need a team. There are lots of teams working on other things, why don't we throw one together for winmodems?
Simply, because one team is insufficient. In fact, each brand (possibly each modem) would require its own team. There are hundreds of different winmodems out there, each requiring its own specialized emulator, tailored to its own specific needs.
Well screw that I say :). I'd rather spend the extra $50 bucks on a real modem and not have to worry about slowing my machine down just because someone wants to make a rediculous profit.
Which they are. The Winmodem PCBs are worth maybe $3 US at most, and they only have to write the software emulation once (rather than putting a new processor on each board). You can do the math.
Here's to another shoddy product in the name of profit! ;)
Michael Gentili
- He's just some guy, you know?
i don't see how these drivers would work. and if they did, they wouldn't be very well optimized.
I just had a quick look at their "graphical wizard".
/proc/pci and a bit of simple code that would come straight out of the hardware spec. How much did it cost again? I want to give them my money ;-)
Now, my experience of writing drivers extends to an RTC driver in NT, a very quick look at the code for an Artec AS6E linux driver and attempts to get the S3 driver in GGI to work. Not really very much.
This Wizard seems to do the equivelant of cat
Yeah these drivers wouldn't be optimized but wouldn't this increase the amount of manufacturer released drivers right at the bat. I sure would appreciate getting a new video card and not having to wait for XFree to be re-released, but instead having a functioning card right out of the box. I can wait for the driver to be optimized.
Before I signed up for this just to check it out a while back, I had never recieved a piece of junk e-mail or spam. Just a few hours after I entered my e-mail for this, I started recieving spam. DON'T USE THIS, all this in addition to the fact that it was pretty much a useless piece of software.
Chris Hagar
"The price of freedom is eternal vigilance." - Thomas Jefferson
It IS a great idea - with a 10 year old existance proof - Mac add in cards from the MacII/NuBus onwards came with drivers in their ROMS - you brough a card home, plugged it in and rebooted and (if the driver writer was doing their job right) it worked out of the box. These days PCMCIA, 1394 and USB plug and play stuff SHOULD work this way too - borrowed your friends camera from his Mac? plug it into your Linux box and it should show up ready to serve images without any software installation - everything should work this way - and when enough devices do that customers expect this behaviour vendors wont be able sell buggy devices. Also the combination of flash ROM and the 'net give vendors a great way to fix buggy drivers in the field. From our point of view the real problem is how do you get the hardware vendors to support more than just M$ software - the simple answer is what's happening today Linux/BSD/etc are becoming critical mass - they have to - or lose out to their competitors.
Or what's to say that they won't charge extra for the hardware because it's being used on an 'under supported' 'minority' or 'rebel' OS?
If it's a portable driver format that's supposed to work on lots of OSs how could they know what to charge you?
Now whether they actually support you - or more likely whether M$ will toss some spanner in the works with the intention of nuking the viability such a system - is another question.
I think this is the same idea as Windows Mini-port drivers.
Works great for things that don't actually need a driver in the first place (like modems and tape drives) But in my experience (with windows) it is not so good for other devices.
In other words, you aint gonna run video with this.
-Peter
I see a lot of people saying how this is an impractical way to create distribution-quality drivers...
Appears to me that this software is for lab work. People make simple recording devices, and then they want a way to get data from the card (which may be an easy-to-use kit) into their own programs.
In this case, cross-platform capability is only so that the user can choose their platform, not so that they can "write once, distribute to everyone".
Not to say there aren't shameless companies who would use this type of tool and distribute the results.
Where is my mind?
mfspr r3, pc / lvxl v0, 0, r3 / li r0, 16 / stvxl v0, r3, r0
Check out Project Upper/Mute, an all-around awesome compiler fra
SPEED. thats one of the biggest problems that i am currently dealing with. the driver that i'm writing was first written for DOS then ported to VxWorks and then the guy who wrote it gave it to me to port to Linux. Besides me having to wrap up the fact that DOS doesn't have any of the modern OS features, like virtual memory, i can't utilize some of the special features that Linux has to offer like bottom halves, and the slab allocator. a HAL (hardware abstraction layer) will only get you as far as a mediocre preformance. i don't think any of us would settle for anything less than the best. i mean isn't speed the why Linux was written in the first place.
[Sigh]...
Well, _I_ thought it was funny, and certainly a good deal more original than "open source hot grits Portman" posts...
Moderators - imagine having a conversation in real life, and apply that to your moderation. By this, I mean if you're in a group discussion (eg
Strong data typing is for those with weak minds.
Strong data typing is for those with weak minds.
Any of you 31337 h4xx0r5 (or indeed someone who knows what they're talking about) out there care to enlighten us all on this?
Strong data typing is for those with weak minds.
Strong data typing is for those with weak minds.
The current Mac OS doesn't have any type of HAL, and driver development is messy. However, a module to implement a limited HAL that allowed WinDriver modules to work in it, wouldn't be impossible.
That said, Mac OS X's driver model basically has drivers act as clients of the Mach kernel, AFAIK. I don't see any reason why WinDriver couldn't be modified to create Mac OS X drivers. However, WinDriver focuses on x86 drivers. They'd either need to create 'fat' drivers (for x86 and PPC) or have it compile PPC drivers as an option.
-- "Those who cast the votes decide nothing. Those who count the votes decide everything." -Joseph Stalin
[UDI] 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.
The decision of UDI vs something else is a different decision than Open Source vs. closed source. UDI also allows for source-level distributions. (It is a common -and incorrect- myth that it is a binary-only interface.) You can distribute your UDI driver as source and it will Just Work on any system that provides a UDI environment.
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.
This is actually a reason to welcome UDI. UDI offers insulation from that. Kernel developers are then free to change things in ways they deem necessary. Perhaps the UDI environment has to adapt. (Better one module than hundreds of drivers.) Since the interface between the driver and the OS is well-defined and versioned in UDI, the drivers - source or binary - see no change. So changes like the recent ones where the locking primitives all got shuffled no longer sink all the drivers.
Just like the system call definition allows the underlying kernel to change without breaking the applications, a well-defined interface between the kernel and the driver allows either to change without impacting the other.
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.
Well-defined interfaces are convenient. Having your driver work on both a 1995 OS and a 1999 OS is nice. (My recollection of Sun version history might be off.) Would you expect your 1995 Linux driver (source or binary) to work on a 1999 Linux kernel?
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.
I'll agree those can be tricky beasts, but they aren't necessarily OS specific. If you're using a driver interface that addresses these issues for you (sometimes with your help; they aren't magic) that's less tricky code that you, as a driver writer, have to fret about. UDI addresses them.
[ UDI, ] like any such effort, it relies on an abstraction layer that interfaces the "real" OS-level driver layer with the driver components themselves.
Although that is one way to implement it, it isn't the only way. Programming is full of abstractions. Consider timer services, for example; at some level, there is a (probably horrible) chip that generates an interrupt once in a while. Well, we certainly don't want hoards of drivers talking to this chip directly so OSes provide services like schedule_timeout() to abstract it. Almost every OS provides similar services and they're all maddeningly different. So it is entirely possible to implement, say, udi_timer_start beside schedule_timeout instead of in terms of it. Viola, no interface to the "real" OS driver layer and no layering costs.
I'm not saying that this specific example makes sense to do, but the point is that common interfaces can be implemented without layering costs.
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."
That's merely speculation. I have seen the UDI code and understand how it performs. Apparently, "the linux people" in your statement have not.
The benefits of improved scalability and detaching policy from implementation mean that UDI drivers can often perform better than with many existing driver models.
Paying for it isn't the problem. I just don't want closed source drivers in my system! Just think about what a driver could do to your system (---> MS Winblows Blue Screens)!
I was wondering if this kind of a system is available for a VMS platform. Since the take over of Digital by Compaq, Compaq has decided to get rid of their VAX's and recommend porting.
I work on a Real-Time simulator that is based on a VAX 4100 running VMS 5.5. The problem with it is that it is connected to a Uni-BUS and a Q-Bus that use customized device drivers. We are considering replacing the VAX with something running either VMS or some flavor of UNIX(or Linux) (even NT although I'm against it).
It would be much easier if we could create a standardized device driver for the current VAX/VMS and then we could port that to another computer with less problems.
This is really only touching on the problem, but if you have any suggestions then it would be a great help.
(sorry if this went a bit off topic.)
cdail@nbpower.com
What I'm not willing to loose is the performace. I bought a 56K PCI winmodem (Diamond SupraMax 2260) for a windows box I built to play internet video games, and was blown away how bad those "modems" really were. After a few weeks, I dug out an old 33.6 ISA real-modem and it was a big improvement.
The current Slashdot moderation system is made by gay communists!
Read This... It is some funny shit. I submitted it as a story way back and it was declined. I guess it wasn't breaking news but I figured that funny sarcastic material about how Microsoft handles 'interoperability'-type issues would go over well here... :)
I thought the whole damn thing about drivers is that they were different across OS's and it was a lot more complicated than just recompiling.
If they have a bunch of translators, doesn't that make the program just HUGE???
Guess that's what they're planning those huge disks for.
bun-fhuinneog agam!
sorry slip of the words =P they will both compile, but they can sometimes produce different results (as far as output goes) i just remember having all kinds of problems at VT submitting code written and compiled in win9x as opposed to winnt 4 or *nix. i havent had the opportunity to write any code in win2k yet, but i doubt there'd be too much difference between nt4 and 2k.
"Patience is a virtue, afforded those with nothing better to do." - I don't remember
"Patience is a virtue, afforded those with nothing better to do." - I don't remember
It exists already in standard and in a test
implementation. It's called UDI. See
http://www.project-udi.org. And what he said --
make it work by the standard first, and if it's
too slow at that point, just add extra-standard
shortcuts to the code.
Someone had to do it.
Ralph Furmaniak
Dina HTML preprocessor, CGI unifier.
"If you want UDI, you're free to write it yourself and maintain your own tree."
That's the whole problem as I see it; the "Linux Community" won't let you write it yourself, not without forking the Linux source and doubling the effort to develop the same OS. They berate the one company actively developing UDI for Linux and openly refuse (before UDI for Linux is even complete) to allow anything resembling UDI to be incorporated into Linux.
The lack of responsibility to users is just plain arrogant, elitest, and mean. Aren't Linux users the ones who target Microsoft for its abuse of users? The message is clear: there's no room in Linux for anyone but those who tow the party line.
DISCLAIMER: I don't use Linux to the extent that many of you do, and I don't claim to be an authority of any sort on the matter. I'm usually a BeOS user, which is usually referred to as the not-free-as-in-speech alternative OS. I suppose this issue hits closer to home with me, as driver support for BeOS is worse than for Linux.
And if that change happens to annoy Big Proprietary Hardware Vendor Inc., tough shit.
And if that change happens to annoy Inexperienced End User Who Wants To Give You Market Share But Can't Because Of A Philosophy Decision, is it tough shit too? More users result in more developers. More developers result in more support. More support results in more things that you want for your OS. Are you willing to sacrifice the opportunity of UDI just because it doesn't jive with your notion of how Linux should be? (Note: that's a rhetorical question there buddy. If you're itching to hit the reply button, quote that question, and say "yes," then you've missed my point.)
If hardware manufacturers want to be assholes, release a UDI driver and claim support then let them. They're assholes; it's their fault. If I want to use the driver, I'll knowingly be sacrificing performance in exchange for operability.
You can boycott the hardware that doesn't have a native driver, hack the driver all over again from scratch, and sign mass petitions to get a native driver. In other words, you can continue to do what you already do.
However, the Linux community has come to the conclusion that this would make manufacturers less willing to write drivers, and hedge the bet that Linux users will be satisfied with UDI drivers. To be more precise, the Linux purists are afraid that Linux users will be satisfied with the UDI drivers and won't be as eager to join mass driver movements.
Linux wants to consolidate its power and levy its mass of users by refusing to compromise, by refusing to give its mass of users what they can use right now.
The want of native drivers is understood and respectable. To deny users a choice just because it makes your job harder isn't. If you don't want users to be complacent with UDI drivers, then tell them so. Expose the bugs, the speed, the philosophical impropriety, and whatever else you think will convince them to be pissed about not having a native driver. But don't take away the choice just because you're too lazy to do it. That's insane and just plain mean.
If what you say were true then there would be no drivers available for any *NIX system, because all of the companies would have signed the fictitious MSFT agreement preventing them from porting.
A well-crafted lie appears unquestionable - Dama Mahaleo
Another point is that you are limited to what abstractions are provided by your toolkit vendor. It might be difficult to use interesting OS specific features. On the plus side, its also possible that by updating the toolkit one could pick up some interesting features for (close to) free.
A well-crafted lie appears unquestionable - Dama Mahaleo
FYI, The NTFS driver is not being dropped because the maintainter "just quit". It is because of lack of info on NTFS + the author is loosing time to work on it. Open source works, you just have to have "source" to work on. The NTFS partition support was basically a "hack", we didn't have any docs or whitepapers that did anything for us.
Perception is reality
If I remember right, FreeBSD has a read/write
NTFS driver.
If you have any platform other than i386 then 99% of the time closed-source is exactly the same as nothing.
Um, so in other words you're just writing normal user mode code. So how on earth do you deal with things like actually accessing the device and fielding IRQs? Well, it goes on:
You have to wonder exactly what they were putting into their device drivers that meant it had anything but IRQ and IO handling... However the interesting bit is:
So in other words, they seem to be implying that you can do everything - handling IRQs, touching the hardware - from user mode, it just might run like a dog. But that's OK because having ironed out the bugs, you can then migrate these bits into kernel mode for an instant performance increase without changing the code. (IMHO any code in your 'driver' which didn't end up in kernel mode has no business being in a device driver anyway, and its rightful place is in the user mode support libraries you ship with your driver. But I digress.)
Sounds great, but two problems spring to mind.
To answer one of the questions ("why isn't everyone using this?") I think the answer is: this is only any good for people needing a quick and dirty solution to access some hardware. This is not an industrial strength solution. This is because the final problem is that to get good performance out of a driver tends to require matching that driver very closely both to the characteristics of the device and also to the operating system.
For example, when writing NT drivers there is a no-brainer approach for accessing user mode buffers to transfer data to and fro between the device and the application. This is fine for getting you going, but it sucks as far as speed goes. If you want good performance you end up interacting at a more grungy level with NT's memory management APIs to make sure that you lock down precisely the pages you want when you want them. It's harder work, but it sure pays off. Now will the code I wrote to do that map naturally onto Linux's mechanisms? I doubt it. (I haven't looked at Linux kernel mode hacking since 1.1.x days, so I have no idea how it all works now.)
To put it another way, I've developed high performance device drivers that ran on multiple platforms. Looking at this product I don't believe it would have been any use to me.
Ian Griffiths
Wouldn't this allow for additional Drivers where there weren't any before though, I mean, I'd rather have a slow driver for a Modem or Soundcard than not be able to use it in my Linux box.
BTW, there was a huge line-up at Corel's booth to get a version of Corel Linux... Windows users are seeking for alternatives...
Not easily and not simple, but IMO it is possible. Having very good knowledge of all targeted hardware platforms, one can create abstractions for hardware (IRQ, port IO, memory IO and mapping, etc) and some kind of portable kernel-specific RTL. I'd developed NT drivers several years ago and NT HAL architecture is very good in this sense. Can somebody tell about Linux? BTW, they didn't mention Apple. Is it so totally different?
Is this like a kernel quasi-shell? Perhaps someone can clarify. (flamebait)
- learn mathematics - shoot dope -
Wouldn't a driver made for say, Windows specifically run far better than a driver made with cross platform code?
By sticking to one system, the code can be optimised for that system and it's efficiency maxamised.
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...
-- Michael Lee Martin
And its likely different for each of the hundreds of kinds of modems.
Different chipsets == different drivers. I'm aware that Lucent released the specs for their Winmodem and corresponding chipset, but there are the other companies of course.
And futhermore they suck, because they eat up processor time.
Which makes them a *real* pain to use on a low-end system. After a month or so of using^H^H^H^H^H trying to use an EigerLabs 56k Winmodem (PCtel chipset) on my old Cyrix-200 system, I took it out and tossed it away. 14.4 connections on lines that are known to be capable of 56k, frequent drops, etc. I now have an ISA 56k modem for use when I'm home from college. Sure, they cost more, but they're worth it IMO.
Would Linux drivers problems such as this? Maybe, maybe not. Point is, while having Linux drivers is good, the device itself also has to be something that works.
=================================
I pledge allegiance to the flag...
of the Corporate States of America...
There should be a "fix" between "drivers" and "problems." Sorry bout that.
=================================
I pledge allegiance to the flag...
of the Corporate States of America...
also remem that the winmodems "that seem to appear in every shipping pc" are like "a free air freshener with every new car purchased" from a local dealer. oh yay, but, are the bulk of them worth a parade? no, they are merely "look, it's got a modem" and not, "look, you very own cisco router and free t1 connection." they are cheap. plain and simply.
2^3 * 31 * 647
This tool is not really for generating a driver, but a library on top of their generic (read: inefficient) device driver. It allows for some customization, but not much (look up WinRT!). I've seen these before, and they don't usually meet the needs for anything more sophisticated than a VGA driver...
Besides, writing drivers under Linux are vastly easier to do than under Windows (NT or 9x), especially with the modularization.
I remember using DOS on a AMD 386DX40 PC. Inside BIOS setup, I have mouse working. Once DOS was booted, I needed a driver. Most modern BIOS can boot from a CD, meaning they don't need a OS driver to read CDs. But you need one for some OS (like MS-ones; I'm not sure for Linux; and I was not speaking about SCSI drives).
Maybe it won't be possible with every peripherals and protocols, but I think most things'll be easier and cleaner if the BIOS were handling them instead of the OS. You won't need drivers, and it will be fast. It could even be kinda plugnplay.
Today's BIOS are reflashable, for those afraid of evolutivity. And it will be safe:
Now, I must recognize it will requires comittee debate between hardware vendors, ISO norms, and it won't result in Open Source code. Vendors won't even need to release their product's specs. But that's what they want.
Too sad I just can't order them to do that ;)
sigmentation fault
Oh, and furthermore, winmodems are clearly not linmodems, so the hell with them. Let them to idiots and AOLers. That's how I see things: pseudo-computer-users surfing a pseudo-internet with pseudo-modem working under a pseudo-OS; and the real world left to us geeks :p.
sigmentation fault
Face it, your typical Joe Linguru doesn't give a rat's ass about a new potential convert, especially a Joe Sixpack one. "New converts means new newbies", they say, "and new newbies means new silly questions on my favorite IRC.".
I've seen many times how elitist, agressive and stupid Linux integrist can be (myself, I prefer to buy a book than to try to ask for help on a mailing list). Nearly as stupid as corporates:
> Smart companies would release UDI driver source (both for the "with enough eyeballs, all bugs are shallow" effect, and to allow the driver to run on as many possible platforms without needing to directly support each binary configuration) and specifications (so that the community could do most of their support work for them, reducing their support costs).
Many corporates just can't see things that way. "If we release our specs to everyone," say the typical Joe Corpobutt, "our concurrent will know how to do the same hardware, and, as they've better engineers than we have, they'll soon sell better and cheapier version of our products! No way!"
> The ported driver would be GPL, but the UDI environment could remain entirely proprietary, and it would not violate the GPL since their code changes wouldn't be a "derived work" of the GPL code."
Nice, really. But legally speaking, you won't be allowed to distribute these drivers. If you don't believe me, here's a quizz:
- As Debian pointed out, you can use KDE but not distribute it, as the GPL
- forbids you to distribute your software if it requires a non-opensource component: Yes/No.
The correct answers are "Yes", "Yes" and "Yes". We'll have the same problem with UDI, which will be to the driver what Qt is to KDE.> Given Stallman's hostility towards UDI (he seems to believe it is a plot for proprietary vendors to rip off free software developers)[...]
Is there anything non "100% pure GNU" that Stallman don't consider as an international conspiracy of proprietarist to eradicate free software? :> (evil grin)
sigmentation fault
That is true about the loadable module memory usage and page fragmentation, but in the grand scheme of things, isn't really all that important if you can't boot your system. :)
--www.mp3.com/kruhft--
Speaking of multi-platform drivers,is it possible to create a Linux/Be/etc. driver that lets you use a winmodem?Is there a project out there trying to accomplish this?You can't immagine how many newbies are stuck with these pieces of crap until they can get around to getting a real modem.And then there are the laptops,if you have a winmodem in there then you're basicly screwed as it's a royal pain to replace.
remove the food that Monty Python loves to email me.
------------------------
Thus Spake ComradePenguin
I'll admit now that I'm no device driver expert, my main skill is applications. But I just wanted to ask how does knowing how to right a device driver for a product help with copying the hardware?. You can copy a hardware product without the need for the drivers, simply by cracking open the case of the chip and examine the design underneath. The point being that at the moment the only way for a hardware company to know that their design has been compied is to physically check the design of the competing product. Therefore releasing the specs for the interface for a hardware product can hardly be that damaging, remember that the competitor will still have to come up with a design that doesn't copy the original to a point where they can be sued.
correct me if i'm wrong, but isnt there potential for security threat here. once the kernel module is installed, wouldnt it be possible for userland programs (other than the intended driver) to be made that could make use of the module for bad things?
since when does pointing out that everyone speculating is just a waste of time qualify as a troll? come on moderators, buy a clue.
sure, there's some intellegent responses posted now, but there wasnt anything but gobbledygook when i first posted this.
Well...I found an excuse to look under the bed, wiggle through the chains and whips, tread through assorted bodily wastes and jolt bottles to find my old winblowz box...in its favorite place. Ungagging it, scraping of the dust and restoring some critical raped hardware...I had a functioning machine...snatched windriver from a friend ... and gave it a try... I'M NEVER GOING THROUGH THAT AGAIN FOR CR@P-@SS CODE & 0-SUPPORT FOR NON-INTEL PLATFORMS!!! We should keep our gear INSIDE the community.
TH3 L@t3X Pr0gr@mm3r...G0d3ss of 0p3n-s0ur(3.
"A driver version should not be tied to a kernel version in the first place. "
Linus and everyone else on linux-kernel disagrees with you.
But don't worry -- someone (probably Intel) will donate a UDI implementation for Linux. Just don't expect any of the normal Linux device driver authors to write to it.
When I hear the word 'innovation', I reach for my pistol.
I see how it could work and (gasp) how it could possibly even be useful, but personally I wouldn't even touch it. I guess it stems from my fear of 3rd party modules. It just seems to me that the drivers this thing kicks out can't possibly be as good as the drivers kicked out by the kernel developers (ie. people who really know what they're doing).
Maybe somewhere down the road it'll be quite the viable utility, but I'm personally sitting the first few generations out.
its really not that hard and yes it can work. Be inc, made a wrapper to compile linux drivers in BeOS. This since disappeared as its a GPL violation, and to my knowledge they only used it once. Its all a matter of wrappers for the most part. Some of which can be done through macros. I myself have done the same with QNX, BeOS, and Linux. Created my own functions/macros for things like pci_find_device(). writing to ports is also easily done. Then you can have IRQ wrappers and macros. Once you get basic functions written its fairly simple to create a skeleton source for a particular function to go along with your cross platform library. And in some cases you could see a performance hit, but that can be minimized greatly by any decent programmer and the constant use of macros. It's really not that tough. It's much like writing NT or linux drivers that work on multiple platforms.
Don't know why it hasn't gone far, but oh well..
Slightly informed AC...
In the Linux world, the binary KPI is not considered relevant. The ABI has remained compatible from 1.2 (when ELF appeared) to the present day and is unlikely to change in the foreseeable future. The source KPI remains consistent within a stable series. Since the source is open and the source KPI is consistent, who cares about the binary KPI?
To this end, BTW, documenting that behavior in detail is a valuable step but all too rare in the Linux world. Documenting dependencies on specific behavior would be nice too.
It's happening. Look in the latest 2.3.99 versions; parts are being documented in DocBook format.
For example, as a filesystem developer I can only shake my head at the Linux VFS and buffer-cache layers.
Try 2.3. You aren't the only one who thought the old way sucked.
What's missing is a widespread recognition that the most important reason to protect code from change is the importance to other components of maintaining its current behavior even in small details.
No. The most important reason to protect code is that it is correct, fast, and maintainable. While one correct, fast, and maintainable solution can be replaced with another that is easier to interface with, no decrease in correctness, performance, or maintainability is considered acceptable. It's true that some of the kernel hackers have axes to grind in some portions of the code. This is true in any project. Unlike closed-source projects, Linux offers you the opportunity to go off on your own, implement what you want, measure its performance, and post your results.
Unfortunately, doing this usually requires foresight in the _original_ version of the code, leaving room for versions or capability flags so that both called and callers know which behavior to expect or provide. Sadly, the code most in need of an upgrade is inevitably also most marked by lack of programmer foresight.
This type of thing has a name: cruft. Programmer foresight is a nice thought, but nobody can think of everything. Everyone tries anyway. The nice thing about Linux is that when a failed effort to think of everything starts to cause problems, it gets replaced. In the proprietary world it stays around forever (IDE, the 640 limit, the list goes on).
>In Solaris or Windows, where most people don't get decent performance anyway That's a pretty offhand and inaccurate statement, at least for Solaris. It's not great, but neither is Linux.
Look, I've used Solaris. I admin it sometimes. It sucks on SPARC, and is simply godawful on x86. I bitch at Linux too, sometimes for other things (like NIS), but when it comes to Solaris I gripe about performance. It just sucks.
I do, unapologetically. If you don't release specs so that an open source driver can be written, I won't buy your product. It's just that simple. It's unfortunate that some people won't switch to a Free operating system because they have hardware that isn't supported, but their annoyance and indignation - and that of the people who have to explain this to them - should be directed at the vendors, where it belongs, rather than at the legions of volunteers who have written excellent drivers for documented hardware. Compromising with the devil is rarely a profitable exercise. I would much prefer Linus to announce today that he will no longer allow binary-only drivers.
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.
No. Firstly, kernel source PIs do not change within a stable series. But what you are forgetting here, since we're talking about binary compatibility now, is that Linux has no consistent or guaranteed kernel binary PI. That's right, none. Linus and everyone else doesn't see the need, and I wholeheartedly agree. Linux is an open source operating system, and the source KPI is guaranteed within a stable series. So given driver source, there is no issue here. The kernel hackers can feel free to make changes that break binary module compatibility, and it only harms binary-only drivers. Big deal. If a change needs to be made, it needs to be made. And if that change happens to annoy Big Proprietary Hardware Vendor Inc., tough shit.
It only hinders development if poor API's were chosen to begin with.
Only as long as those PIs continue to exist. In Linux, when it's determined that an existing KPI (it's not an API if they're not applications after all) sucks, it gets replaced in the next development series. We can do that in an open source world. Your proprietary binary-only world prevents those kinds of changes and instead encourages setting arbitrary limits like the ones you mention ("since we can never change it, we'll just make it as high as we think is necessary today"). In fact, it is the anchor of binary compatibility that holds you to the rocky bottom of 1980's OS technology.
Jury's still out on performance. [UDI]
Not really. Alan Cox has explained in several l-k posts, in detail, why UDI drivers, in Linux anyway, cannot have performance equal to their native counterparts. In Solaris or Windows, where most people don't get decent performance anyway, UDI sounds like a good idea. But in Linux, wherein crazy socially maladjusted individuals pride themselves on removing one cycle from the kernel's execution time, any penalty is too much. The rationale is simple: our OS kicks the living shit out of yours; why should we be the ones to change to your driver model? I have yet to hear a good answer to this question.
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...)
Right. So on my production system, I have three choices: a userspace UDI driver that most likely won't crash my system but will run so slowly that nobody can get their work done; a kernelspace UDI driver that will do God-knows-what to my system; and a 7-year-old battle-tested open source native driver held together by volunteers who know their device better than the people who made it. Guess which one I'm going to choose, even if it means using different hardware?
UDI represents the best hope for "fringe" operating systems (e.g. HURD) to get comprehensive driver support.
This is not a bad point but for one thing: if the people who use those OSs want, they can take a driver from another open source OS and port it. The real "best hope" is for every piece of hardware to have available a programmer's manual. Linux is where it is today because many people felt it was a good use of their time to write drivers for hardware that wasn't previously supported. The same can be said of FreeBSD and other projects as well. If nobody feels that writing a HURD driver for some odd hardware is worth doing, then it won't get done. In 1992, nobody picked up Linux and started using it because it supported their hardware. In fact, some of them picked it up because it didn't support their hardware.
Too much is made today of how to get the computer-illiterate digital have-not GNOME-wanting RedHat-investing Luddite fuckwits to come use our great new wonderful OS. Am I the only one who doesn't really care whether they do or not? Linux is for the people who make it. If someone else finds it useful and wants to use it, they are free to do so by virtue of the license. But it's not the responsibility of the kernel developers to put in support for every two-bit half-assed self-serving proprieatry piece of crap "standard" that comes their way. In fact, in most cases, it's not their job to work on Linux at all. They do it because they choose to, not so that you can feel all warm and fuzzy telling all your 1337 friends how well it supports your brand-new XFR3-5432DSA fuxor card.
By asking this question you illustrate your lack of understanding. The point is not that keeping UDI of of the mainstream Linux kernel somehow prevents proprietary practices. Rather, if UDI is put in (ignoring for a moment the substantial body of technical reasons it should not be), and vendors begin providing the same low-quality binary-only drivers for Linux that they do for 'doze, the new Linux users unaccustomed to our high standards will accept these inferior drivers. Once they have done so, there will be less motivation than ever for hardware vendors to provide documentation ("Why do you need the docs?" "To write a Linux driver." "But we already provide one! See, here - foo4355.o; it works on UP Red Hat 7.2 on Intel only" "But I have a Sun and I run Debian" "You need foo4355.o for Linux"). Don't kid yourself - this is guaranteed to happen. In fact, it's already a problem because binary modules are allowed at all. Thankfully the developers refuse to support kernels with binary-only modules loaded. Still, UDI will only make the problem worse.
Hardware support for Linux is pretty good right now. While not everything is supported, a little of everything is supported. If you want a nice graphics card, you can get one -- not any graphics card, but you don't need any graphics card, just a single one that works well.
UDI would keep even many good companies from releasing their specs, because they wouldn't have to do so to provide support. It would hurt Linux and its bretheren.
That's not the way things work. The ideal of providing the perfect abstraction is a nice, but unattainable, ideal. Innovation very often is a matter of changing the boundaries of abstraction. And Linux is great because there is that freedom to innovate. That freedom is one that is used a lot in the development of the kernel, and is part of what keeps the Linux kernel from getting too unwieldy.There will be a UDI 1.1 or 2.0 or something. Even if the people behind UDI are quite intelligent and thoughtful, they aren't oracles, they can't see into the future, they can't predict what the demands on future APIs will be.
Open Source drivers don't need to predict the future, because they can change. If other Unices want to get the hardware support that Linux has, they can GPL their kernels and make their kernel APIs compatible with Linux's, and then they are set. This isn't wholely unreasonable. And if they don't, well, tough luck for them.
If Linux wants to get better hardware support, UDI offers almost nothing. Is someone going to make a UDI driver but not a Linux driver, because UDI has a 10% larger share? No. Are they going to make one for UDI because it's binary-only? Sure, but that's not what Linux needs.
I think it's highly unlikely the HURD people want anything to do with UDI. Don't support it for their benefit.In such cases, there may never be a "real" driver, as the device may be so esoteric that there will only be ten of 'em on the planet.
In the long run, it might be preferable to have some generic "bus" (think: RS-232, Parallel Port, USB, IEEE-488, FireWire, ...) to support all sorts of such devices, and have the support code sit in user space. That is what is likely to, in the long run, limit the usefulness of this system...
If you're not part of the solution, you're part of the precipitate.
With a BSD-like license, the notion that KRFTech "owns" portions of the driver would make it just as unacceptable to try to push a WinDriver-based driver into FreeBSD or NetBSD as it would be with Linux, and perhaps moreso. In effect, *BSD sets a "higher" standard for freedom in this regard, in requiring that anything that becomes part of an "official" kernel be released under a license that allows people to build it into proprietary systems. That's a somewhat more "intense" requirement than is provided for in the GPL.
The fact of having permission to release "binary-only" versions would permit some releases of software that the GPL would forbid, with the net result that "You win some, you lose some" when taking WinDriver into a BSD-related context.
But the crucial point here is that Licensing Really Is Important.
There are some legitimate disagreements that may legitimately persist over which approach to licensing of "free software" is preferable.
My position is that this parallels the multiple forms of noneuclidean geometry, where there are multiple viewpoints that provide useful mathematical insight.
The universal is that which ever "ethic" you prefer, it is critical to understand and think through the use of your "favored" licensing scheme, as there can be great troubles otherwise.
If you're not part of the solution, you're part of the precipitate.
SciTech has been contracted by IBM to make a "light" version of their drivers, so that IBM can take developers off video card support.
I have heard good things about performance, but it could be because the previous IBM or manufacturer drivers were worse or just the switch to the newer GRADD driver model.
Meanwhile, Scitech keeps improving a beta OS/2 version of their commercial "full" drivers
__
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
as far as i know, the difference is that its not just a 2%-5% drain, think of it as a real time 2%-5% drain... unlike most applications, the modem can't just sit waiting for resources, it must have it all the time. so if it ends up waiting for too long, because you started some resource hungry app, then "blip" there goes your network connection.
Its spelt "L-I-N-U-X", but pronunced as "Free Beer"
Maybe we can get the people who make win modems to create a module for us linux folks now.
Joseph W. Breu
For the PC platform the single driver multiple platform idea is ingenious. I mean just imagine the ultimate efficiency of creating allowing your drivers and hardware to penatrate every market, appliance, etc. If you bring it one step further you can allow your laser printer to say a palm pilot or gameboy. Anyone with common sense can see that this is good for the PC market.
Hardware engineers are up to the task of making universal standards and interfaces for computers. The limiting market I am sorry to say is the software market. Who will be in control of the technology behind the universal drivers? Will it be open or closed. If Microsoft is in control the answer is simple: You won't have universal drivers since all they want you to run is windows! What if Sun is in control? They will want their Java technology to get into the picture.
To make a long story short, as long as these companies are fighting for domination and complete control, smart ideas like univesal drivers will not hit the PC market to a great degree.
It means that the device specific software is in the application instead of the kernel. This is OK for things like industrial control and data acquisition, where the programmer writes a custom application for a specific task. It is useless if you want a standard device driver for a sound card, video card etc. The operating system and its applications assume that each class of device driver, such as sound or tape, provides a standard set of features specific to that class. The driver provided with this software does not provide those features. Every application that uses the device driver must include device specific code for the hardware that it supports. It is similar to games on MS-DOS where the sound and video drivers were part of the game, not the operating system.
Mea navis aericumbens anguillis abundat
Does it much matter if it's ineffecient? Once the driver was functioning correctly on multiple platforms, you could start including conditional code to optimize performance on particular platforms.
In radical cases, you might branch and rework the architecture to bring it more in-line with the target OS's native device driver interface, but even in that case you would have a couple of advantages - a working reference implementation (regression testing, anyone?), multi-platform support, and the ability to perform the more expensive optimization work under various OS's if and when you determine that enough customers are asking for it.
Heck, release the Linux/BSD versions under the appropriate licenses, and you'd probably have an optimized version for each OS within a few months, without much more cost than developing a single driver for Windows.
All in all, sounds like a good deal; makes me wonder why more companies wouldn't take this route. Is the company new on the scene, or is their product just not mature enough yet to be worth spending time on?
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
Ah! Thought I saw this on their page:
So it looks like they provide for some level of perfomance tuning without even going the #ifdef/branch & rewrite route.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
It's a quick and easy way to add the increasingly important Linux checkbox to their marketing gloss without giving up any of their docs or paying someone to write a driver.
Since UDI exists, you can't prevent this kind of game. They can still write a UDI driver, say "we support Linux!" and add "by the way, you need this patch to use our UDI driver" in the fine print. The glossies can still have that little checkbox, regardless of how hostile Linux kernel hackers may be to UDI. The solution to this problem is user education, not rejecting UDI environment code for a perceived (but illusory) idealogical benefit.
But maybe we're just splitting hairs anyway. The simple facts are that, politics and licensing aside, UDI will not be a part of mainline Linux anytime soon, if ever, and that this decision has been made for technical reasons, rightly or wrongly. We can argue the nontechnical side of things, but the people who matter don't care in the slightest.
Let's get real here. The decision was not technical -- plenty of low-quality drivers are allowed into even stable-series releases, even with little technical merit. As long as it's marked "EXPERIMENTAL", Linus will allow almost any extra drivers to be included. UDI environment code could be marked "EXPERIMENTAL", and it wouldn't impact those who don't enable the option. This wouldn't hurt anyone, and should be done. However, the kernel developers don't like the idea of supporting UDI, so they find technical excuses for why it "cannot" work to avoid including it.
I thought the Open Source way was to give the code a chance and let it succeed or fail on its own merits?
I'll give you another example. Years ago, Oracle said they were reluctant to consider porting their database (in part) because Linux had no support for raw disk devices. Linus (for whatever reason) hated the idea of raw I/O and insisted that all disk I/O must be buffered. His response to this genuine need was to the effect of "screw that, I don't think we need it, and Linux will never support raw I/O to disk devices." (Not an actual quote.) He insisted that he would reject patches for raw disk I/O even if someone else did all the work. It was because he didn't like it.
So, what happened with raw disk I/O in the end? It's going to be in the Linux 2.4 kernel. This is a tacit admission that there is a real need for this feature. It was resisted for years only because Linus preferred his way. (Of course, now devfs is being used as a technical excuse for this delay, because it "would have required too many device numbers" -- that never stopped other UNIX vendors...)
UDI is a lot like raw disk I/O -- it's against the preferences of the Linux kernel developers, and they don't feel it's needed. Nevertheless, there is a real need for this stuff, and it will probably happen eventually in some fashion; refusing to allow it just causes unnecessary strife. It's clear that when it comes to UDI, Alan Cox doesn't like it. Must we go through the same struggle as with raw disk I/O?
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
It's the dichotomy of the Linux community, isn't it? On the one hand, you have people wanting to replace Windows everywhere with Linux everywhere. On the other hand, people are lamenting about how the lower quality of the average Linux user as more newbies show up.
We can't have it both ways, folks. The average computer user never gets far past "clueless newbie" in their skills. Now that Linux is becoming more of a mainstream OS, we're stuck with more average users. It's a trade-off that's tough to evade. If you don't like it, switch to an OS like HURD that is more hostile to average user. (Of course, if you could move UDI drivers from Linux to HURD, that would be a lot easier...)
Many corporates just can't see things that way.
Quite true. However, some companies are starting to see the light. Matrox, for example, is paying for an accelerated Linux driver to be written for the G400, to be released as Open Source. The result? They get a competitive advantage. (I just bought a G400, actually, for this reason.) Even if most companies don't get it, you only need a few enlightened ones...
Nice, really. But legally speaking, you won't be allowed to distribute these drivers. If you don't believe me, here's a quizz:The correct answers are "Yes", "Yes" and "Yes". We'll have the same problem with UDI, which will be to the driver what Qt is to KDE.
(This response is based on my understanding of copyright law, but I am not a lawyer; standard disclaimers apply. Could a real lawyer please check this and comment?)
This is an oversimplification. Copyright law only allows the GPL to exert influence over "derived works", which is why "mere aggregation" on a distribution media does not bring other code under the scope of the GPL. (This is explicitly acknowledged in the GPL, in fact.) Since KDE is a derived work of its own GPL code and the proprietary Qt code, the GPL should apply to the whole. (Hard to enforce when the KDE developers don't seem to care...)
UDI, on the other hand, is a specification which is not under the GPL. If Microsoft were to implement a UDI environment (an idea they're probably more to than Alan Cox is), that UDI environment code would be a derived work of the UDI specification, and could remain proprietary. Meanwhile, if a GPL'd Linux kernel driver were ported to make a UDI driver (perhaps by Microsoft), that UDI driver would be covered by the GPL, since it would be a derived work of the original GPL code. It would also be a derived work of the UDI specification, which wouldn't interfere with using the GPL.
So, this hypothetical scenario has a proprietary UDI environment, and a GPL-licensed UDI driver. Each is kosher on its own. The key question is, what happens when you combine them? As I understand it, if the proprietary OS loads the UDI driver dynamically, the GPL couldn't apply, because there would be no derived work for it to apply to. (This is akin to loading a GPL'd user program with a proprietary OS.) A direct quote from the GPL:Here is the "mere aggregation" quote from the GPL:Even from the words of the GPL itself, it seems clear that a proprietary OS with UDI (which is clearly identifiable as a separate work; it could also use proprietary UDI drivers) and the GPL'd UDI driver could even be on the same distribution medium without violating the GPL. Static linking, on the other hand, probably does bring the whole under the GPL. All the proprietary vendor needs to do is keep it dynamic loading, and I think they're in the clear.
Is there anything non "100% pure GNU" that Stallman don't consider as an international conspiracy of proprietarist to eradicate free software?
Probably not!
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
If you have any platform other than i386 then 99% of the time closed-source is exactly the same as nothing.
That's usually true right now. A big part of the reason is the cost required to port to other platforms and support them. On the other hand, if no actual porting is involved (just a recompile), even proprietary companies might be more willing to release binaries for multiple platforms, since it would expand their market for a smaller cost...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Consistent interfaces are the lifeblood of continued interoperability, whether you're talking about GUI fluff or kernel grunge. If lots of people call a function or use a data structure, great care should be taken to preserve that item's behavior or change it only for very good reasons.
Thank you!
Finally, someone who understands the real issues here and why the ad hoc methodology used until now is so limiting...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
In the Linux world, the binary KPI is not considered relevant. The ABI has remained compatible from 1.2 (when ELF appeared) to the present day and is unlikely to change in the foreseeable future. The source KPI remains consistent within a stable series. Since the source is open and the source KPI is consistent, who cares about the binary KPI?
This is a serious problem. Do you remember what a nightmare it was to manually upgrade a.out systems to ELF? Even with all the source readily available, recompiling all that code is very painful. The more code, the more painful it is. Now that it's been stable under ELF from one kernel version to the next, hasn't life been easier? Application developers don't have to worry about capricious changes in the ABI for their ELF binaries; why aren't device driver developers accorded the same courtesy? This deliberate nonchalance about stable interfaces isn't "studly hacking"; it's amateurish and it shows.
There's over a million lines of device driver code in the Linux kernel. That's a lot of code to review and modify when changes are made. Device driver development could be less painful if a solid API/ABI (or KPI/KBI if you prefer) could be trusted not to change often. UDI aims for that kind of interface stability. It also aims for high performance. I don't know if it will meet these goals, but I'd rather give it a chance instead of running it out of town on a rail.
Imagine the uproar it would cause if the kernel hackers suddenly decided that they didn't care if ELF changed with every kernel revision and couldn't be bothered to keep backward compatibiltiy with old ABI's, and refused to accept such efforts contributed by others. After all, who care, if you have source code and the API hasn't changed? Oh, you don't have source to Oracle? Too bad, proprietary code sucks -- that'll teach 'em not to release their source!
This attitude is childish, and impedes the progress of the entire Linux community. Clean, solid abstractions are the basis of complex code. Do you really think you'd have such fancy browsers and word processors if they had to twiddle the bits on the screen at the application level instead of using GUI toolkits? I doubt it.
We need more stable interfaces, to make way for the Next Big Thing, whatever that may be. Right now it's hard to see the forest for the trees.
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
How will we know until we see it? If it sucks that badly, they'll probably either revise the UDI spec to make it perform well (which would eliminate the main argument against it), or punt and implement a traditional interface (which would be a tacit admission of failure). I don't know what will happen, but I wish them luck.
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
I was told by someone at SCO that Monterey would have UDI as its sole API for drivers, but after a little searching, I found a reference on SCO's website about it -- "UDI device driver model" is listed under "Common Enabling Technologies".
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
"A driver version should not be tied to a kernel version in the first place."
Linus and everyone else on linux-kernel disagrees with you.
Are you suggesting that their opinions are beyond even debating then?
Currently, device driver modules must be tied to the Linux kernel because code written for one kernel version often won't work with another version. If the API and ABI are stable, then you only need to version those and not every kernel code change, large and small.
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Who says free software needs to compromise? UDI is a technology that has significant potential benefits for free software, independent of political considerations. Yes, UDI also offers significant benefits to commercial, proprietary developers, but that's incidental. Don't cut off your nose to spite your face; use the best technology instead of hobbling yourself for purely political reasons.
Again, where exactly is the compromise here? How would enabling UDI drivers enable disreputable proprietary behaviors that aren't already being practiced anyway?
As for whether developers want to work on drivers, I have no objection if that's how they want to spend their time. However, I'm concerned about people who insist that vendors shouldn't write a driver and should only release specs so we can write the driver. Even with specs, not all drivers get written, and little-used drivers might be just as poor quality as typical vendor fare. I believe that the vendor should be expected to release open source to a basic driver and specs.
If they only release specs and we write the code, we're subsidizing their efforts -- let them shoulder the burden of making their products work. Once they've gone that far, it's more reasonable for them to ask the community to fix bugs and enhance the driver. Again, why should they expect us to do their work for them?
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
That's true for early adopters. When I ordered my computer at the end of 1992, I made sure to select hardware (e.g. Adaptec 1542CF) that was supported by Linux and NetBSD, since I wasn't sure yet which I would run. (I quickly decided I liked Linux better.) Selecting the best hardware for Linux is obviously ideal, but not everyone has that luxury, or necessarily even knowledge of which hardware is best.
For those who are using existing hardware, I don't think UDI would offer any benefit. It is unlikely that hardware manufactures are going to provide support for old hardware via UDI, because there's little economic benefit -- they've already sold their product, support or no support, so there's no reason put extra effort forth (unless you want to keep your good name, but that seems to mean little to most hardware manufactures).
I'll tend to agree with you here -- vendors probably won't rewrite drivers for old hardware. On the other hand, old hardware is more likely to have Open Source drivers available. New hardware tends to be more troublesome; if new hardware started becoming available with UDI drivers, that hardware could be used immediately. If open source drivers were later written (or maybe higher-performance Linux-native drivers?), you could switch later.
Of course, there's always the "don't use that hardware" argument, but that attitude doesn't mesh well with the quest for World Domination (tm). Face it, your typical Joe Sixpack doesn't give a rat's ass when he buys his computer whether the hardware has Linux drivers -- but if you can make it run Linux anyway, and better than it runs Windows, then you may have a potential convert on your hands...
Hardware support for Linux is pretty good right now. While not everything is supported, a little of everything is supported. If you want a nice graphics card, you can get one -- not any graphics card, but you don't need any graphics card, just a single one that works well.
Linux probably has the best device driver support of any free OS, and better than many proprietary OS's. It can't match Windows 98, but it might actually have better support than NT 3.51 or NT 4.0 did? Linux is reaching critical mass and starting to become a significant target market for vendors, although still less important than Windows.
Now that Linux is more mainstream and less of an "alternative" OS, what about the other alternative OS's? What about HURD, FreeBSD, NetBSD, and even BeOS? They may all be great OS's, but they lack the driver support of Linux (especially HURD and BeOS), which is a barrier to entry. Years ago, people used to complain about how they'd like to use Linux, but it had little driver support -- now you hear the same about HURD or BeOS. Won't we be better off if new OS's can compete on features and merit rather than sheer volume of available device drivers?
UDI would keep even many good companies from releasing their specs, because they wouldn't have to do so to provide support. It would hurt Linux and its bretheren.
We can't stop companies from being shortsighted. You can always boycott such companies; that's nothing new. Smart companies would release UDI driver source (both for the "with enough eyeballs, all bugs are shallow" effect, and to allow the driver to run on as many possible platforms without needing to directly support each binary configuration) and specifications (so that the community could do most of their support work for them, reducing their support costs). Dumb companies that keep their source and specs closed will suffer a competitive disadvantage, which should encourage them to change their ways. That's not the way things work. The ideal of providing the perfect abstraction is a nice, but unattainable, ideal. Innovation very often is a matter of changing the boundaries of abstraction. And Linux is great because there is that freedom to innovate. That freedom is one that is used a lot in the development of the kernel, and is part of what keeps the Linux kernel from getting too unwieldy.
At over 1.6 million lines of code, the Linux kernel is already somewhat unwieldy. (Nothing compared to Windows 2000, of course.) Over 1.1 million lines of that is drivers; decoupling driver development from kernel development would give both kernel developers and driver developers more freedom to innovate, because they wouldn't spend so much time tripping over each other!
While I agree that attaining a perfect abstraction is probably impossible, UDI looks to be a very, very good one. I'm amazed at how flexible it is, especially for an API designed by committee. It remains a matter of speculation whether or not it will be fast enough to be a system's primary API, but SCO and IBM must have some faith in it -- I'm told that UDI will be the only device driver API supported by Monterey, the "High Volume Enterprise UNIX Platform" (as their whitepaper describes it) being developed for Merced. I'll be interested to see if that succeeds; it sounds like a demanding environment.
There will be a UDI 1.1 or 2.0 or something. Even if the people behind UDI are quite intelligent and thoughtful, they aren't oracles, they can't see into the future, they can't predict what the demands on future APIs will be.
Of this, I am certain -- sooner or later, UDI will surely have to be revised, unless it dies completely. (The obvious reason why a revision might be necessary would be for performance reasons.) Project UDI has prepared for this; the UDI specs and the drivers themselves are versioned; if a UDI environment and UDI driver don't support the same API version, they will be able to tell. An OS supporting UDI 1.0 won't accidently try to run a UDI 1.1 driver and crash the system; it will simply refuse to run the driver at all.
In any case, hopefully such revisions would be rare occurrences. An OS could, of course, support several UDI versions simultaneously if necessary. Really, what are the odds that the UDI specification will change more often than the Linux kernel driver API already has?
Open Source drivers don't need to predict the future, because they can change. If other Unices want to get the hardware support that Linux has, they can GPL their kernels and make their kernel APIs compatible with Linux's, and then they are set. This isn't wholely unreasonable. And if they don't, well, tough luck for them.
Actually, the cat's out of the bag on this one. The very existence of the UDI spec presents an opportunity for proprietary OS vendors (even Microsoft) to support UDI in their system, then port Linux drivers to the UDI model. The ported driver would be GPL, but the UDI environment could remain entirely proprietary, and it would not violate the GPL since their code changes wouldn't be a "derived work" of the GPL code. It would be a derived work of the UDI spec, which isn't bound by the GPL. They can do this whether or not the Linux kernel developers support UDI.
On the other hand, this bugaboo isn't worth getting too alarmed about. Microsoft has little incentive to "steal" drivers this way -- they already have the most comprehensive driver support, courtesy of hordes of bootlicking vendors. Proprietary UNIX vendors have an incentive, but they still have a problem with the value proposition of proprietary systems -- increasingly, Linux is becoming recognized as a best-of-breed UNIX platform in more and more areas, and the proprietary UNIX vendors are bound to fall by the wayside sooner or later, with or without device driver parity with Linux. In short, this one is a red herring.
If Linux wants to get better hardware support, UDI offers almost nothing. Is someone going to make a UDI driver but not a Linux driver, because UDI has a 10% larger share? No. Are they going to make one for UDI because it's binary-only? Sure, but that's not what Linux needs.
Vendors can make binary-only Linux drivers now, and some are starting to. This is more problematic, because it makes it difficult to upgrade the Linux kernel.
As for why vendors might release UDI drivers instead of Linux ones, it's a question of leveraging their investments. If a vendor is targetting Unix-like systems, getting all versions with UDI would be better than investing in learning each individual native interface. Also, the UDI driver could actually be easier to write with a stable API that hides issues such as MP sychronization from the driver... I think it's highly unlikely the HURD people want anything to do with UDI. Don't support it for their benefit.
Given Stallman's hostility towards UDI (he seems to believe it is a plot for proprietary vendors to rip off free software developers), you may be correct in believing that the HURD people will have nothing to do with UDI. That doesn't mean they wouldn't be shortsighted for that. If they ever want "the GNU system" (with HURD) to replace "GNU/Linux", they'll need to address the driver issue, and UDI is a better solution than trying to race Linux in these driver parity wars...
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
As you admit, it's already a problem where proprietary vendors are releasing binary-only Linux drivers and refusing to release source or specs. New Linux users can be just as lulled by these (potentially) low-quality binary-only native Linux drivers. This is a user training issue and a community issue. The problem isn't going to go away on its own.
It all seems like a wash to me. How does UDI actually make this problem worse than it is anyway?
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Yeah, OTOH win95/98 being closed source and having a "stable driver interface" really helped in getting a ntfs driver for it.
The same goes for drivers for aged hardware or hardware from vendors which went down the drain, when you want to use them in newer windows versions. This will not work with older/bad nt4 drivers. Try the pppoe driver winpoet 1.2 from ivasion in win2000 and see how well it works or tell me why every graphics card manufacturer comes out with drivers for win2000.
This "stable interface" is mostly a myth.
but this is not a feature, this is a misguided cure against non-opensourceness. And - it works well most of the time, but not always, take a brief look at support.microsoft.com and search around. There are many problems with drivers across service packs and nt/2000
In many of the comments Im reading here make me think of the almighty hill much of the Slashdot communitity sits on.
Here is a company TRYING to do a good thing and help people out making driver writing easier within the space. No nobody ever claimed that this method of doing things was faster then regular code. One word: DUH! Its running outside the native OS OF COURSE its not going to run as fast. This from the same people that carry on about Transmeta chips and how fast their going to run and blow up Intel.
Listen, everybody step down from their high and mighty and come down to the normal user for the moment.
1. Joe Blow user wants simple running, if you want to keep Linux within the confines of the computer elite then keep this attitude about anything easier coming along. Someone how Grandma likes running Windows 95 because its easy and she doesnt want to recompile a kernel.
2. Keep putting anything down that might actually help the OS that wasn't suggested by Linux or Bruce Perens. There are a lot of smart people out there and if you continually dog good ideas instead of trying to nurture them and WOW maybe improve on them then Linux will become pardon for lack of a better term "an imbred communitity."
3. Not accepting the fact that some stuff will be closed source. Not all companies can make money from support. Reverse engineering of chipsets becomes significantly easier with all the specs laid out in front of you. Think about the company's interest for a moment:
a. Release closed source drivers for Windows and Mac and not worry about competition. Put up with Linux user requests.
b. Release specs to the Communitity and have competitor figure out what I'm doing and move before I can. Whether this is a logical or reasonable arguement doesn't matter.
Personally, I like the UDI idea and think its about time. Whether it works as quickly or not as native code really doesnt matter to me if I can run Solaris, Win2000, RedHat, and Windows 95 on the same system without having to download different sets of drivers for each OS. You can't tell me that this problem cannot be beaten with a little humility, ingenuity and hardwork within the community instead of a "It CANT BE DONE, ITS HARDWARE and NATIVE argument." Hell if Linus can program a processor to emulate x86 code and nice people can get Windows to play in Linux sandbox and vice versa then this can be done. Dance with the same girl you brought and live by the motto "It just works." Worry about upgrading performance later and free your mind. Live by the motto below:
Hangtime
If you continue to think the way you always thought, you will continue to get what you have always got. - Anonymous
Hangtime's collary
If the Linux communitity adopts the same attitude it has had, it will never grow beyond the elitiest of computer users and never pass Apple in marketshare.
I can see how a "write once run many" theory can be employed with apps, as apps can use abstractions layers (winelib etc) to abstract the running code.
As far as drivers go, with all the changes in the kernels, different compilers, different platforms (x86, ppc, alpha,...), I just don't see how this can be easily accomplished.
Its pretty possible that the "superdriver" stub could be a binary only module too from the looks of things.
I didn't read far enough in to look for licence restrictions, redistribution royalties etc.
I am certainly no kernel programming expert but it seems to me that there could be some definite performance issues with this approach, aside from these other issues I have outlined.
Would anyone suitably clever care to comment on the performance issue here?
-- Oh Well
>Linux has no consistent or guaranteed kernel binary PI. That's right, none. Linus and everyone else doesn't see the need
Then they're idiots. Consistent interfaces are the lifeblood of continued interoperability, whether you're talking about GUI fluff or kernel grunge. If lots of people call a function or use a data structure, great care should be taken to preserve that item's behavior or change it only for very good reasons. (To this end, BTW, documenting that behavior in detail is a valuable step but all too rare in the Linux world. Documenting dependencies on specific behavior would be nice too.) Failure to preserve behavior will lead to other components failing, often in very subtle and non-obvious but no less severe ways, and in ways which require more than a mere recompile to address.
One of the biggest problems with Linux is the lack of good internal abstractions that allow people to do different things without interfering with one another. For example, as a filesystem developer I can only shake my head at the Linux VFS and buffer-cache layers. It seems like there's always some asshole changing a function or data structure or locking schema to make their own "neat idea" work, without considering the impact their change will have on others. I've seen project after project lose time from this lack of development discipline. Many times I've seen people make the situation worse by countering one hack with another instead of improving the underlying abstraction so it serves everyone's needs better.
Some code is "politically protected" by the fact that some Major Figure in Linux development will scream at you when you touch it. Other code is protected by being hard to understand, or in other words bad code is less likely to change. What's missing is a widespread recognition that the most important reason to protect code from change is the importance to other components of maintaining its current behavior even in small details.
>In Linux, when it's determined that an existing KPI (it's not an API if they're not applications after all) sucks, it gets replaced in the next development series.
And that's great. Sucky interfaces should be replaced with better ones. However, "sucky" includes "incompatible" as a major component. Major surgery should be undertaken only after understanding and agreement have been reached on the goals and ramifications, and all too often that is not the case.
Even when an interface is completely overhauled, I see no good reason not to maintain compatibility with at least version N-1 of that interface. Unfortunately, doing this usually requires foresight in the _original_ version of the code, leaving room for versions or capability flags so that both called and callers know which behavior to expect or provide. Sadly, the code most in need of an upgrade is inevitably also most marked by lack of programmer foresight. Humility is not a common trait in this community. Everyone thinks their version can never be improved upon, so they don't build in the features that allow future improvements to be made with minimum pain.
>In Solaris or Windows, where most people don't get decent performance anyway
That's a pretty offhand and inaccurate statement, at least for Solaris. It's not great, but neither is Linux.
Slashdot - News for Herds. Stuff that Splatters.
>The source KPI remains consistent within a stable series. Since the source is open and the source KPI is consistent, who cares about the binary KPI?
I thought I was answering that question, but apparently not clearly enough. In brief, then: relying on people to change their source when you change an interface is an invitation to error, because sometimes they don't. Sometimes they're not around to do it. Sometimes they don't recognize that they need to change their code. Sometimes they change their code and introduce a whole new bug in the process. It's better for system stability if their code continues to work without intervention, thank you very much.
>Try 2.3. You aren't the only one who thought the old way sucked.
I'll believe it when I see it. I've seen enough false claims about what has improved in past releases that I'm just a little bit skeptical. That code had a _long_ way to go, and kt seems to have a lot of stuff about this filesystem or that filesystem still needing updates to comply with the new interface. My build of 2.3.99-pre4 just last night kept failing in umsdos because of this stuff. Still seems to be very much a work in progress, from where I sit.
>While one correct, fast, and maintainable solution can be replaced with another that is easier to interface with, no decrease in correctness, performance, or maintainability is considered acceptable
That's pretty much what I've been saying. Unfortunately, the new interface is often not provably faster or more correct than the old one - nobody even bothers writing or running the tests that would allow them to make such a statement out of knowledge rather than bravado - while the changes have severe implications for the correctness of other code that worked fine with the old interface.
In my experience, the people who are most afflicted by the "rewriting fixes everything" are junior programmers. Senior programmers have learned the hard way that rewriting something that's anywhere near functional _will_ introduce errors not present in the original, that doing it properly involves ten times more effort in regression testing than in coding, and that if you're not going to do it right you should leave well enough alone no matter how it offends your aesthetic sense. It's too bad that in the open-source community the people whose egos won't be satisfied until they've left their mark on the code - no matter how poorly justified their changes are - tend to outnumber and outyell the people who know and care about producing quality software. The signs of the creeping rot that results from all this marking of territory are everywhere in Linux, and some of the big dogs are the ones pissing on things the most.
>The nice thing about Linux is that when a failed effort to think of everything starts to cause problems, it gets replaced. In the proprietary world it stays around forever (IDE, the 640 limit, the list goes on).
Neither of those examples is of an attempt to think of everything. In fact, both are examples of the _lack_ of foresight that is antithetical to what I'm talking about.
>I've used Solaris. I admin it sometimes
And you suppose that have less experience with Solaris? Or, for that matter, with Linux? Why? Remember, people who disagree with you may occasionally do so because _you_ are the one who needs educating.
Slashdot - News for Herds. Stuff that Splatters.
I'm fairly certain Heinlein didn't make it up, but he did make it popular.
Cris E
St Paul, MN
Check out www.i2osig.org for an example of another project. I am working on an I2O FibreChannel-RAID adapter at my job.
I2O allows hardware vendors to concentrate on making great hardware/firmware. The people who know the most about the OS, the OS vendors, can then concentrate on making great device drivers. The spec is open but currently you have to join the sig to redistribute the headers. Alan Cox, who is working on the Linux I2O drivers, is part of an effort to change that.
There are I2O drivers for every major OS except one. You guessed it...Windows. Microsoft's I2O drivers have been infinitly delayed. They are next expected as part of Win2k SP2 if ever. What is crazy is that they are a major sig member and can't even get a working set of drivers. Thanks to them I can now claim to be a NT4/Win2k device driver export. Joy.
Supported devices include LAN, Tape, Block Storage (usual disks), Generic SCSI and more.
-- soldack
While that SEEMS like a great idea that would work, we already have (some) trouble getting SOFTWARE drivers to work properly for some hardware on Linux, if the company won't release software drivers, what's to say that they'll release firmware drivers?
Or what's to say that they won't charge extra for the hardware because it's being used on an 'under supported' 'minority' or 'rebel' OS?
I built Mac cards like this years ago - they were a dream to support.
There is a downside however - once you do this you freeze an API
If it works, it's a really cool thing. Just imagine: there would be no more reasons to use Winblows. Every Vendor could compile his drivers with this tool. ...).
But on the other side: 1.) Drivers made by this tools will be rather big (not to say huge) and slow (slow as a snail
2.) The tool isn't Open Source and the drivers won't be, too.
3.) It's hard to believe that this works for ALL kind of drivers.
This has got to be some sort of weird performance issue with a universal driver.
How could you write low-level code for various devices and get ANY sort of compatability, especially Windows CE, which doesnt traditionally run on x86 systems while most of the others do.
Point here is, i dont think this is such a miracle bullet. How could it possible do all of that without some sort of emulation, or a REALLY REALLY good object model to compile down with.
It could work if you abstracted basic commands and stuff, but since things like SoftICE and DDKs that sort of thing are still highly used in making driver code, then i dont think this product is a miracle.
Of course it always comes down to marketing, i suppose.
--jay
microsoft cant even get the same code to compile the same way on both the 9x and nt... so how does krfTech do it??? the answer is simple... you have to plug the 'windriver' kernel module into whatever os you are running. its the windriver, i assume, that interperets "cross-platform" hardware calls. anybody out there have any experience w/ this software package... does system performance take a hit?? --dexsun
Personally I would rather have a poorly performing driver than not have a driver at all. Since with Linux I am usually in the latter category for just about every odd device around I think that something like this would make a great interim solution to a very difficult problem. Unfortunately, you would still have to write the driver in the first place because this is not going to just work for the current drivers on NT. Is this a good idea? Only if you are a company that is trying to be first to market.
"If I can see farther it is because I am surrounded by dwarves." -- Murray Gell-Mann
What I find interesting, is that all the big commercial UNIX vendors are listed as "participants" (SCO, Sun, HP, IBM), but there are NO LINUX VENDORS participating.
What's up with that?
The linux kernel is monolithic, meaning that just about everything, including drivers, is compiled into the kernel image. This has changed with the advent of loadable modules, where the drivers could be loaded into the kernel memory space on the fly when needed. This allowed for a smaller memory footprint for the kernel boot image, without requiring any of the drivers to be removed from the system.
There is some overhead during module loading, but once the module is loaded, there really should be no performance loss/gain over a regular compiled driver statically linked into the kernel.
Of course, i just re-read your command and realized that I didn't really answer your question, but maybe I got a couple of 31773 points for the pseudo-explanation :-)
--www.mp3.com/kruhft--
It wouldn't be to hard to make a cross OS driver developement library. The drivers them selves would not be that much bigger either, but they probably would end up being inefficient. Each OS has certian parts you can accelerate in different ways, and there's little tricks you can do specific to your card for a certain OS to get it to run faster, these would be lost in a generic cross OS driver developement kit.
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!