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
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.
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?
This was not an insightful comment. Win32 drivers are a lot more complicated. In Linux, there isn't much to implementing the file operations block, and going from there. In Windows, managing those IRPs and power management requests is a lot trickier. The NT kernel API gets tricky, and learning about the IRQLs and all of the NT kernel features is really hard. Plus, you don't get kernel source. It's a real pain in the ass. If I were given the assignment of writing a Linux driver vs a Windows driver, I'd take the Linux driver -anyday-. It's infinitely easier.
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-