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."

Comments

reading

[The Clockwork Troll]

This book might shed some insight.

Re:reading

[trendyhendy]

And you can read the whole thing for free here.

Re:reading

[Yohahn]

With this book, if your devices aren't anything too obscure (i.e. it fits in a traditional class of device) it will be easy. It is a fairly straight forward book.

(You may also want to look at the porting to the 2.6 kernel series that has been written over at Linux Weekly News As an aside, I'd really advocate subscribing there.)

When your device is a new class of device that linux isn't used to, it can be harder (e.g. when the phonejack cards came to linux, a new api for them had to be made).

Note, I've only limited experience, but this is what I've observed.

Re:reading

[trouser]

I was about to post the same thing. This is a seriously useful book. Some excellent examples which will enabled a C programmer familiar with the standard tools (ummm, GCC and a text editor) to write a skeleton driver and hook it into the kernel in no time. Then all that stands between you and freedom is stealing an intergalactic space craft.

Re:I have no idea

[Anonymous Coward]

Perhaps a quick visit to the SciTech Website would be in order I am running their SciTech SNAP Graphics for Linux driver(s) currently... from what they say on the site they support 200 graphics cards in their OS/2 product and around 125 in their Linux product. So it would appear that they would be a good group to speak with... by the way I am running an i865 on one system and an ATI rage on the other and the same driver works great on both - may even be faster than the XFree86 drivers! you can find contact information for SciTech here:

http://www.scitechsoft.com

from my experience their support team is very good and can most likely give you some answers

Professional experience

[gibson_81]

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*)

Pretty Straightforward

[AstroTech]

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.