Slashdot Mirror
Writing a Linux Device Driver on Company Time?
DriverSubversion asks: "Excuse the anonymity: I'm covering my back and that of my company. My company makes some USB and PCI peripherals, currently only supported under Windows. Several of us have pointed out that there is a large cross-over between the people who buy these things and the people who run linux - and thus it's in the company's best interest to develop device drivers for Linux,as well as Windows. Now while our boss is kind of convinced that this might sell some more units, he understandably wants to know how much it will cost to write and maintain the drivers... and where better to ask than here? So has anyone else gone though this? On scale of 1-10, how hard is it, (1 being 'extremely easy, 2 programmers could do it' and 10 is 'a team of no less than 20 programmers, lawyers and salesmen'). Keep in mind that our intent is to keep the code up-to-date, GPL-compliant and in at least some major distributions."
But I want some shiny new drivers, so I'll say its a 1.
Why not fork?
This book might shed some insight.
There are no karma whores, only moderation johns
For part of my college senior project I developed a linux USB device driver. It wasn't too bad, working on it part time I went from nothing to something that I could probably release in about two weeks. It was the first real linux device driver or USB project I had ever worked on. Of course I kick ass daily.
-73, de n1ywb
www.n1ywb.com
One programmer could write a usb driver for your device in a matter of days. The hardest, absolutely the hardest thing about writing a driver for linux is getting the docs on the chip, and those docs being complete and accurate.
Maintenance is very easy, however 2.0 -> 2.2 you'll have to do something, 2.2 -> 2.4 you'll have to do something, 2.4 -> 2.6 you'll have to do something, 2.6 -> 2.8...the linux croud delights in changing everything around. Revisionist thinking and all--if it's clean now it was never ugly, dirty code before. The cleanest code in linux is in the device drivers themselves. The infrastructure the device drivers use is, well, less than fresh. And if anyone tells you RTFM ask them where is TFM?
Well, from reading the source of a couple drivers, it looks like most are one or two person deals.
:)
3ware, for example, is a company that provides open source drivers that have been accepted into the linus tree. They seem to be primarily written and maintained by Adam Radford alone.
There's also a userspace component to manage raids, would your devices also need userspace apps developed to make them useful? That's one question you have to ask.
Anyway, good job. It's always good to see devices with open source drivers that don't suck. (Make sure yours don't
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Take a look at many of the USB serial drivers; tiny drivers, very clean. The USB storage drivers, same thing (assed-up hardware is the reason for complexity in those drivers).
Writing a device driver for Linux is no more difficult than writing a device driver for Win32. You're in Ring 0 (for ia32) for both, so a poor driver can cause the system to come down. My suggestion would be to take a look at what you've written for win32, estimate how much of that you can keep, and write the linux kernel abstraction layer code.
If you've written the driver correctly it shouldn't be a very large task at all, I would imagine.
The easiest way to get a Linux driver would be to give find an interested developer, give them a free device and detailed documentation, and answer any questions they have. If you're working on a tight budget, this might be the best option.
There are lots of people who attempt to write a driver for a device, but fail only because the manufacturer won't give them information. IMHO, this doesn't make much sense - if someone wants to help you out for free, why would you stop them?
You don't want the drivers in distros -- you want them in
Linus' kernel. Don't worry about liason with distro vendors.
Worry about liason with vger.
Since understanding the device, finding its quirks, and
designing protocol is the overwhelming bulk of the work
of writing a device driver, a reasonable rule of thumb is
that adding another platform will entail an additional
10-20% in manpower. Since the gap between a WinXP
driver and a Linux driver is relatively large, the high-end
of the scale is a closer approximation: Take the
development time for the Windows driver and divide by 5.
Now for maintenance, the new platform cost is much higher,
because each platform has its quirks, etc. You do get to
amortize some stuff over the platforms (no need to
diagnose protocol bugs twice, etc.), but it doesn't count
for a whole lot, so I would estimate that adding a new
platform will entail 80-90% again as much in maintenance
costs.
However, for an open source driver, you will quickly find
(if your hardware is at all useful) that the chore of forward-
porting maintenance as the kernel develops will be largely
assumed by the user community, so give any open-source
platform a -25% maintenance cost tick, at least.
Customer support issues are an entirely different ballgame,
and depend so much on your audience that I won't venture
even a guess -- keep in mind that customer support for
a smaller community typically is less work than is a similar
level of support for a larger community -- and Linux
users are accoustomed to self-support and community-support.
win_cost = win_dev + win_maint + win_support
lin_cost = lin_dev + lin_maint + lin_support
lin_dev = win_dev * 0.2
lin_maint = win_maint * 0.6
lin_support = win_support * k
Fill in k.
-I like my women like I like my tea: green-
I'm not a driver developer, but I've had to look into the possibility of cross-platform USB (and other) drivers before. Do yourself a favour and take a look at WinDriver (no, I have nothing whatsoever to do with the company or the product).
The initial cost can be a bit steep, but the ROI could well be worth it. The suite allows you to write a USB driver that is source-compatible over Win98/Me/2K/XP/2003, Linux 2.0/2.2/2.4, and WinNT, for USB 1.1/2.0 and UHCI, OHCI, or EHCI.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
I have done some driver work, build and debuging and linux is a driver writers dream compared to windows. I would estimate that a linux driver will consume about 50% as much time as a windows drive writing either from scratch. I reality, you may have a lot or reusable code from the windows drivers so you could be looking at less. Also do take the advice of other posts and get the basic driver out ASAP, and allow the OS community help out on the rest.
For the most part, writing a linux device driver is pretty much the same difficulty as writing a Windows device driver. The real question is, do you really want to make your driver GPL compliant? See, you'll be giving up some pretty important IP that you may not want to give up. Now somebody else could come along and make a device that behaves exactly like your company's device, just because you gave away interesting tidbits about how your hardware works. Initially you may gain some acceptance and increased revenue for doing this, but in the long run it may end up sabatoging the product you're trying to support. I know I'm probably gonna get flamed to high hell for this, but I'm personally not the biggest fan of the GPL. You may want to contact your HW engineers and lawyers before you dive to deep into doing this. They may have a much different take than you on supporting linux.
So technically speaking, writing a driver is going to be the same difficulty as far as programming, but much more complicated as far as the business decision involved.
Does your company support OS X as well? Just remember that Mac customers tend to have the extra discretionary income to purchase all sorts of Firewire and USB goodies... Be a sport and advocate for a multi-polar OS environment, Win32, OS X, and Linux... I relinquish control of the soapbox...
"Right now, somewhere in this world, Scott Baio is plowing a woman he doesn't love," - Peter Griffin, *Family Guy*
I was hired to do something similar; first, port existing ISA drivers from VxWorks to Linux, then port again from ISA to PCI ...
The time it takes to port the drivers in itself isn't very much - I spent one and a half year in that company, but that was because that's how long it took them to get the hardware for the PCI device I was supposed to drive working. The actual driver, for working and tested hardware, should be a couple of weeks for one coder, full-time.
When it comes to complexity, that varies a lot. Since I suppose you've been working on the drivers for Windows, you already know most of the hardware stuff, so yuo won't find it very difficult. Also, the kernel has a number of support functions for PCI (probably for USB too, but I'm not sure on that) which allows you to speak to the device in a fairly "high-level" language. Usually, you just call pci_register_device with your vendor and device ID's, and then you get a pci_device struct for each device the kernel can find. I assume something similar exists for USB.
I'd recommend getting an O'Reilly book on device drivers, and looking in the PCI and USB subsystems in the kernel; that should be enough. So, to rate the difficulty, I'd say a '1', since much of the code can be shared between the drivers (you could even create both drivers from the same source, with a "kernel mapping library" to interface with Windows/Linux) and since, as many others have already said, the hard part about writing a device driver is to figure out how the hardware is working.
Oh, and you'll definately want to enable "Magic SysRq" on your development box, 'cause every single mistake your driver makes can cause an OOPS (my favourite was when I accidentially storde the driver name in an auto variable, so every time I tried to unload the driver, I got an OOPS *S*)
I have written several device drivers for both Windoze and Linux. In my opinion, the Linux drivers were far more straightforward to write and maintain. As long as I could get _complete_ information for the hardware, I would choose to work on a Linux driver over a Windows driver if I were given the choice.