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?
My strange mind has for some reason decided you work with Hauppauge and you want to finally give us drivers for the WinTV PVR series. Let me say right now if we actually got official working Linux drivers for this to use with MythTV, we'd be eternally grateful, everyone would thank you repeatedly, and we'd buy more cards/boxes =] I'd look at how the ivtv driver's coming... it's GPL by definition, so you might be able to expand on that.
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
The hardest part of getting stuff to work under Linux is the part where you're trying to understand how the thing works. Since you make the devices, your engineers will know which register does what.
The actual writting of the driver should be that hard. Writing linux drivers is very well documented and there seems to be a lot of example code at kernel.org *grin*.
I think you need to look at all the options, and compare them to the long run after-effects it will have on your code. Other harware companies have varying degrees of driver support for linux, so you could maybe try to analyse the market's responses, or maybe see how many companies had to lay off programmers when the going got tough.
OTOH, if you could somehow just pay one guy to lead the open-source driver effort, even if only part-time, the costs of supporting linux could be quite minimal.
Your complex question requires a complex answer. I would say Pi.
I haven't lost my mind!
It is backed up on disk...somewhere...
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.
Your complex question requires a complex answer. I would say Pi.
Pi isn't a complex number (at least not one with an imaginary part).
2 + 3i, however, is a complex number.
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
That's the question.
How long will it take for ( some unknown number ) of our ( unknown skill and experience level ) developers to write a driver of complexity level ( X ).
What resources will be devoted to maintaining it? Documenting it? Adding features?
Will it be as fully supported as the current Win drivers?
Oh, your boss noticed that if "several" of his own techs are interested in Linux, that there must be a huge number of techs (and non-techs) involved in Linux? Some companies are awfully slow at figuring that out.
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.
Hi,
/etc/ scripts to set things up and a relatively feature complete user space library to abstract some of the more arcane features of the hardware away in about a month. The driver was not exactly trivial since the hardware was dumb and had to be polled in a soft real-time fashion. Basically poll, dump into ring buffer in kernel space. Reads and writes operated on the ring buffer. IOCTL's controlled the start/stop of polling. Learned much about how page faults are handled. Get Arangelli's book from O'Reilly and rock and roll. Maintenance is pretty straight forward.
I did this around the time when kernel 2.2 was shiny and new -- proprietary goofy hardware on PCI bus chained to something you could open,close,read,write and ioctl along with necessary
If your company will let you do it make it GPL, otherwise load dynamically.
Tell your boss this. I buy alot of computer hardware that needs to work under Linux as well as Windows. If I have the option of buying a device with drivers for both OSes, I will buy it rather than a device with just Windows drivers. You will be loosing out to vendors that have linux drivers as well as windows drivers.
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*
Release hardware specifications and document how the hardware works. Maybe even write an initial proof of concept driver. Of course, finding people interested enough in the hardware to write a driver for it is the trick. Just a suggestion...
Join Tor today!
You have to be able to do the following: 1) open the device; 2) close the device; 3) read from the device; 4) write to the device.
Go here (it has info on this): http://tldp.org/LDP/khg/HyperNews/get/devices/devi ces.html
Basically there is already USB support in the kernel, so you would need to start there. There are many supporting funcitons. Good luck.
Only 'flamers' flame!
Does slashdot hate my posts?
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.
So... you're saying that he'll be running around in circles instead of just cutting straight across?
(Pi: the ratio of a a circle's circumference to its diameter. But you knew that.)
Give me my freedom, and I'll take care of my own security, thank you.
lin_users=win_users*0.06. :-)
Any hardware that is microsoft only I will not buy unless
there is no other product available for my customer to
complete their work.
Any company that comes out with a windoze only device
loses my business starting with day one.
Even when the customer has no idea about linux, there is enough good equipment around that's linux compatible that
I am still able to give them the best deal with the best equipment.
I do this only to make sure that any subsequent owner
of same said hardware WILL have the linux option available
to them.
I've been doing this for years.