|
 |
| Sat, Sep 06th | home | browse | articles | contact | chat | submit | faq | newsletter | about | stats | scoop | 17:45 UTC |
|
|
login « register « recover password « |
|
| [Article] | add comment | [Article] |
|
|
|
Linux often sits far on the trailing edge of hardware support and plays catch-up on everything from USB to video cards. Vlatko Kosturjak offers his thoughts on how to improve the situation so new hardware is usable under Linux ASAP. Copyright notice: All reader-contributed material on freshmeat.net is the property and responsibility of its author; for reprint rights, please contact the author directly. Recently, I got a Logitech USB Web camera which I wanted to use with my laptop, which is running Linux Mandrake. I eagerly connected it. The USB daemon recognized that I had plugged in a device and tried to find a module which would be suitable for it. Unfortunately, none was found. At that point, I knew Hell was waiting for me. I searched the Web and Usenet for information on how to make my new camera work under Linux, but with no luck. I read the kernel documentation about Logitech Web cameras. I even found some support, but only for the parallel version. The documentation also stated that Logitech refuses to give any specs or info on their products. I downloaded the 2.4 kernel, compiled and installed it -- but still with no luck. I even thought about modifying that parallel driver to support USB, but had no time for that. As an average programmer, I'm skilled enough to make necessary modifications to the kernel, but an average desktop user surely won't cope with it; he has problems even with compiling downloaded kernel source. In order for Linux to become a desktop OS, this should be fixed very soon. Not very happy with the situation, I decided to write this article and share some ideas on how things should be done to improve device drivers for various hardware devices under Linux. First, let's face the current model of Linux device drivers: Most drivers are shipped with the kernel source already. A small number of them comes on various CDs, either in binary or source form. Those, however, are usually outdated. While the process of writing a device driver, making the required hardware, copying software CDs, and releasing goes on, time passes. Meanwhile, new versions of the kernel are released, with the latest-and-greatest fixes/features and also with a new-and-improved API for device drivers which is, of course, incompatible with the old one. So I thought about making a universal API for device drivers in the Linux kernel core that wouldn't change for a long time. If it ever needs to change, the old API should be preserved for compatibility. The standard API means that I can both compile the source (with same headers/function calls) and load the binary module of a certain device driver under any Linux version. Perhaps this concept should be adopted by other free OSes as well (*BSDs, for example), so that device drivers can become more and more universal as more OSes adopt the concept and standard. Resolving platform-specific issues could be done through a top-level device driver API that would be translated to some bytecode variant, just like Java. This would mainly be intended as a temporary solution for close-minded companies; it would just buy time while companies that don't recognize the power of Open Source come to their senses. If that would take too long, a just-in-time driver compiler could be implemented that would speed up the driver itself (just like a JIT compiler for Java). That would make close-minded companies happy enough to release drivers, but their drivers won't be as fast as those of their competitors, who published them in source form. This could lead the closed source company to release their drivers in source form too. Voila! We'll soon have an Open Source world! This would greatly speed up kernel core development as well as device drivers development because most of the drivers would be developed and shipped separately from the kernel source. A single developer could concentrate on writing either core or device drivers, whichever he's currently working on. It is also easier to debug such code. I emphasize that the process of developing and testing drivers would speed up because you could first test them with the specialized driver API, and then rewrite them into fast C/C++/asm variants. If Linux wants to be the OS for an average desktop machine, some of these points must be taken seriously until the world becomes fully Open Source. If not, maybe some new Open Source desktop OS should take these ideas for realization. Author's bio: Vlatko Kosturjak is 21 years old and lives in Nasice, Croatia. He is the director of Kost d.o.o. and a regular writer for the Croatian computer magazine PC-CHIP, where he writes mostly about Linux/Unix/BSDs. He is an active member of the Croatian LUG and maintains their award-winning portal. He contributes to various GNU programs and is the original author of XPLSISNJASP, FakeBO, MultiSeti, etc. You can send mail to him through http://www.na.linux.hr/kost.html T-Shirts and Fame! We're eager to find people interested in writing articles on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an article gets a t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about. [Comments are disabled]
[»]
Accessing the device file hi --
[»]
I figure this might be relevant The FSF's view on UDI (which is a superset of what's being proposed here).
[»]
Closed but freely available source code? If a company made a linux driver for hardware, it wouldn't neccessarily
have to be binary compatible for that kernel - source but maybe not
binary.
[»]
Re: Closed but freely available source code? (sorry, i' very bad in english)
At least one company do that already: nVidia. You can download SRPMS for
nVidia's DRI kernel driver and compile it for your own kernel. It worked
well on my computer.
[»]
Why wont companies give out information on devices? Can anyone really see a good reason for a hardware manufacturer to not give
out information on protocols?
[»]
Re: Why wont companies give out information on devices?
--
[»]
it is clear you are a dreamer... Your ideas resemble my own thoughts at times. Your observation that drivers are coming way too slow is correct. But then you fall in your own trap. You write articles... and fall back into that habit, but the quality of the content drops dramatically due to that fact. Fact is, that the proof of the pudding is in the eating. Try _prooving_ that your solution is right, and then Linus will listen :-) (maybe). I even looked at your programs, and found that they were all lightweight. Fortunately, kernels are not lightweight. Don't consider it a flame (hell, I'd be flaming myself for being such a lousy programmer), just being descriptive here. Remember Theo de Raadt's words: just a few excellent coders out there (or something).
[»]
don't be dumb The best way to speed up linux driver development
is to not buy stuff that doesn't have a linux
driver.
[»]
Re: don't be dumb
[»]
newbus architecture You should check out the newbus architecture in FreeBSD 4.x (I believe taken from the NetBSD kernel). It's a very abstract way of writing device drivers and the API will be unchanged throughout the 4.x series. Compare this to the linux kernel where there are no such promises of compatibility and drivers are written on a very adhoc basis.
[»]
Re: newbus architecture
[»]
API or ABI? As far as I can tell, the Linux device driver API is stable; otherwise, modules would not only have to be recompiled when the Linux kernel is updated, but would also have to be edited by hand to make them compliant with the new API. What Linus seems to be rejecting is an ABI which would keep modules binary compatible across kernel versions, but would involve, at least according to Linus, assorted cruft and ugly hacks to build up in the kernel. It seems that in the comments and the article, the concepts of an API and an ABI get mixed up.
[»]
Why not use UDI? Why not use UDI? The Universal Driver Interface. It can be found here: http://freshmeat.net/projects/udiref
[»]
Re: Why not use UDI?
--
[»]
You can do it I was in the same position except this time with a Microtek USB scanner. I rang up Microtek branches all over the world trying to get the specs out of them. I ended up reverse engineering the protocol with a guy I met on a mailing list called Oliver Neukum and writing the driver. This is pretty easy, though it might sound daunting. I wrote a program called usb-robot now at http://usb-robot.sourceforge.net. to help.
[»]
Why didn't you asked this on the linux-kernel mailinglist???? If you had read some archives of linux-kernel you would know why this doesn't work: 1 A 'stable' api means that you will be stuck with old mistakes for a long time, there is a reason why kernel interfaces change, namely to make them better. 2 You are making it easier for the manufacturors to make binary only drivers, and thus they will never need to give their specs away. This might work well if you have a popular system. But don't expect them to release a driver for x86, ppc, arm, mips, superh or whatever linux runs on this week. 3 You already don't have to work on the kernel for writing a device driver, when making a modular driver you only have to know a few kernel functions that you have to call. I have written several drivers and know almost nothing (but learning) about the inner works of the kernel. 4 Building layer upon layer upon layer will make your driver slower and slower and slower. 5 Most important: Linus doesn't like it :) Jeroen
[»]
Re: Why didn't you asked this on the linux-kernel mailinglist????
[»]
Re: Why didn't you asked this on the linux-kernel mailinglist????
[»]
About as temporary as income tax (which BTW was introduced to Oz in 1939 as a
``temporary measure''.
[»]
Device Drivers The real problem with device drivers is that companies have gotten into the habit of not releasing specs for their hardware. Which is much more literally like buying a car with the hood welded shut that the case of closed source software. Anyhow, if the hardware could be reverse engineered, drivers could be written in whatever language (C, C , ASM?) given that they were accessing a given set of structures which the device describes. That is, all devices are basically memory ranges which have different meanings according to the device's state. So, a small langauge with keywords like state, struct, byte, bit, word, dword... would probally be enough to describe the device. Writing the driver, and the userland interface, is another two stories... but the device description should be seperate to enable easier revision of the driver.
[»]
Re: Device Drivers
[»]
it's not going to happen in Linux Linus has said that he doesn't care about making things easy to add to the kernel, so I doubt this is going to happen. That attitude has both plusses and minuses. I think it was a good attitude to have for the initial kernel and the small systems it ran on. On current machines, things are different. What I would want for kernel extensions and drivers is a safe language together with dynamically bound methods. That would make kernel modules less version dependent, more easily debugged, and less error prone. That's nearly impossible to achieve in C. A well-written C library might do the trick, or kernel support for some other languages (but there aren't a lot of choices, and they are all pretty obscure: Modula-2, Oberon, Objective-C, natively compiled Java come to mind). Sorry, I guess we have to wait another 10 years for this one.
[»]
Re: it's not going to happen in Linux
[»]
Re: it's not going to happen in Linux
[»]
Re: it's not going to happen in Linux WHO?
A list of the companies that have issued Linux drivers for their equipment
would be a boon. Perhaps as an adjunct to the Equipment HOW TOs accompanied
by the reply one gets when asking companies for their cooperation. I have
been looking into this and found out that HP for one says they do not
support linux drivers. Hp's French division has linux drivers for a lot of
server based equipment. Looks like the short term profit motive outweighs
the long term health of the company.
[»]
Re: it's not going to happen in Linux Advansys SCSI adapters ship with Linux drivers. Netgear NICs ship with Linux drivers. At least one sound card (Zoltrix Nightingale) ships with Linux drivers. All source, some of it borrowed under GPL, and some of it written by the manufacturer under GPL.
[»]
UDI SCO have been @ it right what you want is UDI which means that Solaris and Linux oh not forgeting unixware ALL sahre drivers so go and help out program their USB for them http://projectudi.sourceforge.net/ this has been going for about 2 years regards john jones
[»]
Re: UDI SCO have been @ it Hey John;
Yeah. But what did Matt say about UDI and Linux? The part that we could
understand, I mean.
I so wish that more people knew about UDI, and could implement it very
well, and that the kernel would start using it on a peer level with the
binary drivers.
Hardware vendors think of the OS world as Windows, Mac, Solaris, Linux and
Unix. They release 3 drivers for one, and think they need to release only
one driver for the rest. They NEED UDI, but don't know it. What? The
ability to write drivers not only for all UNIX-like OSes at once, but for
all versions at once? AND be furute-proof? That's even better than their
current bet of planning and fearing driver rewrites for all new M$ OSes.
In this case, they'd write it just the once, get three, and need never
revisit the code again except for bugfixes and features.
Then again, I wish for a lot of things.
- bish
[»]
API is not the issue. Does Microsoft write drivers for Logitech hardware? The solution is a large enough user base to make linux driver development economically viable to the hardware companies. The other solution is to research your purchases ahead of time. The third solution is to write them yourself. A stable API would only mean that people could get more use out of drivers they write themselves. That doesn't actually encourage driver writing, not does it solve the problem - companies think linux drivers are a waste of money, and, to a large extent, they are correct, What is not a waste of time is opening the specs for writing the drivers, but that's a whole 'nother can of worms. See ya, blue
[»]
RE: Logitec , harwdware under linux....
The situation on *newest* hardware are since years the same :
Just after you can buy such new "staff" no driver
exist.
A few days / weeks / moth or Years later - one day there exist one fine
driver - even there are mutch users with programmer skill....
some examples are given :
- winmodem
- sound drivers
- usb staff
- mutch mutch more
be shure : linux driver Programming works like a snowball system - even
more users than faster writing ..
Kindy regards ,
One Linux user that uses Linux for 9j now.
--
[»]
Re: API is not the issue.
[»]
Free programming available I had exactly the same experience. My USB Quickcam works only on my Windows side, on the rare occasion that I decide to boot it. If Logitech were to post the hardware documentation I would happily write a driver for it, for free. It isn't going to cost anything for Logitech to increase their market share. If companies were slightly more enlightened, they would seed some of their hardware to a few open source programmers who are even slightly likely to succeed is much cheaper than hiring a programmer to write a driver. Sending out 20 free quickcams to 20 wanna-be-device-driver-writers is much cheaper than hiring a programmer to do the work. darrell
[»]
Re: Free programming available % Sending out 20 free quickcams to 20
[»]
not realistic a fixed API for drivers ? naah, that would mean a frozen driver api design (and the design should evoluate because of other needs in the future than now will have to be addressed differently, we saw redesigns of all major kernel subsystems yet, not only because the new design is better, but because it does fit the needs of today) or, if the design changes, a backwards compatibility layer, i don't think its a good solution. bytecode drivers ? nope, because the windows equivalent of those drivers will be faster, and everyone will start saying windows is faster than linux for most hardware. the current system ? yeah! opensource drivers get integrated in the kernel, bugs are fixed, performance gets better, we have a _lot_ of drivers supported, and if the api changes , the drivers are adapted too. companies can release binary-only drivers for stable kernel series that already matured (like current 2.2.x) with modversions on, so the drivers will work on every late 2.2.x kernel.
[»]
Re: not realistic
[»]
This has been proposed many times before For the sblive driver originally, etc. There was also an effort out there to make a unified ABI (application binary interface) to allow drivers to be written for one OS and be used on many, but it was shot down with the same reason that this one can be: Interfaces change because they simply don't work one way with an updated model, or were poorly implemented. The other reason why vendors don't support linux most of the time for commidity hardware such as webcam is low returns on investments. They're already writing drivers for Win98 WDM/Win2k WDM (they're not the same binary wise, and you still have to verify that the drivers work correctly on both OSs), Win95, Win95SE, and sometimes Win NT4. Not to mention MacOS if its USB gear. Linux's USB implementation is rather young, and probably a moving target. The returns that these companies make developing drivers for 4 or 5 OSs already is probably pretty low. Not to mention the fact of licensing issues, etc. Sometimes companies don't own the technology that they use in devices and the company that controls it won't release programming information. The only way to fix this is for linux to get enough market share to be able to make demands for hardware support.
[»]
Releasing specs is the only answer.
They shouldn't have to write drivers for yet another OS. If they bent to the pressure from Linux users and released drivers for Linux kernels, then they'd just come under pressure again when the *BSD users what to use it. This, as you say, is a foolish way to spend resources. The way for these companies to support all operating systems, maximising their market share, is to release hardware specs sufficient for other people to write the drivers for whatever OS they choose. Zero investment on the company's part, and the market decides which platforms they want supported. > The returns that these > companies make developing drivers for > 4 or 5 OSs already is probably pretty low. They are hardware companies; why are they spending so much time and money on writing software and keeping it current? > Not to mention the fact of licensing issues, etc. > Sometimes companies don't own the technology that > they use in devices and the company that controls > it won't release programming information. Then they have painted themselves into a corner, and they have no-one to blame for their wasted efforts on writing and maintaining drivers for a dozen platforms. This is where the pressure needs to come from; the hardware companies should realise that they must get themselves in a position to release full specs for their hardware, otherwise companies that are able to do so will eat their lunch because they can be supported on every current operating system with no extra investment from the company.
No, this is just as short-term as asking for BeOS as an extra platform; it places more burden on the hardware company for very little return, and is no help at all when then ext great platform arrives with its hordes of users screaming for support. Hardware companies -- don't spend another cent on writing binary-only drivers that you must continue to support for as long as your users scream at you -- do release full specs to your hardware so that people can use your hardware in many more places than you can spend money to support.
[»]
Ask that to Linus Linus does not like the idea of stable kernel interfaces. He says they slow down development (because you have to be backwards compatible). And thay "allow binary only drivers" which are the main reason of crashes on windows platform. I would like that happen too, but i fear i will not be able tyo see in in foreseeable future.
[»]
ITs called I2O, and it exists already in Linux Kernel The exact thing that you are talking about is called I2O and is already an industry standard and in the 2.4 version of the Linux kernel. This still suffers from the problem that nobody writes I2O drivers.
[»]
Re: ITs called I2O, and it exists already in Linux Kernel
[»]
Re: ITs called I2O, and it exists already in Linux Kernel
I2O... that's an Intel market-creation scheme, right? If I understand
right, OS Vendor support for I2O is dropping sharply because there simply
is no demand for it. It's a catch-22, but at least until some IHV produces
an I2O device that people want, on which end of that catch-22 do we want to
be?
|
|
