Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Space Software Linux

Writing a Linux Device Driver on Company Time? 65

Posted by Cliff from the how-hard-is-it...really dept.
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."
This discussion has been archived. No new comments can be posted.

Writing a Linux Device Driver on Company Time? More

Writing a Linux Device Driver on Company Time?

Comments Filter:

  • I have no idea (Score:5, Funny)

    by CableModemSniper ( 556285 ) <.moc.liamg. .ta. .odlapacnagol.> on Thursday July 24, 2003 @11:37PM (#6529036) Homepage Journal
    But I want some shiny new drivers, so I'll say its a 1.

    • Re:I have no idea (Score:2, Informative)

      by 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

  • reading (Score:5, Informative)

    by The Clockwork Troll ( 655321 ) on Thursday July 24, 2003 @11:39PM (#6529051) Journal
    This book [oreilly.com] might shed some insight.

    • Re:reading (Score:5, Informative)

      by trendyhendy ( 471691 ) on Friday July 25, 2003 @12:13AM (#6529247)
      And you can read the whole thing for free here [xml.com].

    • Re:reading (Score:5, Informative)

      by Yohahn ( 8680 ) on Friday July 25, 2003 @12:23AM (#6529292)
      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 [lwn.net] 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 (Score:4, Informative)

      by trouser ( 149900 ) on Friday July 25, 2003 @02:24AM (#6529806) Journal
      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.

  • USB drivers are pretty easy (Score:3, Funny)

    by n1ywb ( 555767 ) on Thursday July 24, 2003 @11:39PM (#6529052) Homepage Journal
    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.
    • A good portion of the USB subsystem seems to be the result of a college project.

      Try finding out what this means:

      usbdevfs: USBDEVFS_CONTROL failed dev 10 rqt 128 rq 6 len 18 ret -110

      Google has lots of questions asking, but noone answering.

  • It's pretty easy (Score:5, Interesting)

    by Anonymous Coward on Thursday July 24, 2003 @11:43PM (#6529071)
    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?
    • 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.

      If you can convince the PHBs to release it under the GPL, then you don't have to spend time or money maintaining it. One of the kernel janitors will probably port it to new kernels.

      • Re:It's pretty easy (Score:4, Insightful)

        by Micah ( 278 ) on Friday July 25, 2003 @02:27AM (#6529817) Homepage Journal
        If you can convince the PHBs to release it under the GPL, then you don't have to spend time or money maintaining it. One of the kernel janitors will probably port it to new kernels.

        Maybe, but I hope you don't give hardware companies those kinds of ideas.

        A hardware company really should, ideally, maintain the drivers for their own products AND work with the kernel janitors or maintainers to keep an up to date copy in the Linux kernel sources.

        The kernel guys do great with most of the drivers they write, but it seems like it's best for the hardware company to do it 1) out of courtesy, to prevent others from having to maintain drivers that make the company money, and 2) for quality control -- the community might not know how to get the most out of the device.

        • A hardware company really should, ideally, maintain the drivers for their own products AND work with the kernel janitors or maintainers to keep an up to date copy in the Linux kernel sources.

          I really think that just accurately documenting your hardware and providing the documentation for free or a nominal distribution cost (which should then imply some nice hardcopy AND a digital copy) is sufficient. I don't feel companies have any responsibility to maintain anything.

          Remember, money talks. So buy d

    • Easiest way to create/maintain a driver (Score:5, Insightful)

      by Anonymous Coward on Friday July 25, 2003 @12:32AM (#6529332)
      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?
      • if someone wants to help you out for free, why would you stop them?

        Answer #1: the GPL.

        Now then, before the flames start -- please keep in mind that I am a staunch Open Source advocate, okay?

        Let's say that the interested, free developer writes the hottest Linux driver imaginable for the manufacturer's wonderful version of gadget A. The open GPL code base for the driver is also an open book to the implementation of the hardware & chips inside the gadget, whether for cracking, hacking, writing twisty b

        • Of course, that leads to my rule of thumb for hardware selection. The more secretive a company is about how to simply interface with their product, the crappier it is. There are only a few reasons to be afraid:

          Fear that someone will clone the chip: If it's that easy to clone from nothing but a register spec, it's nothing special, move along. If it's meant to be a low cost item, it must be too expensive. If it really was the cost leader, no amount of cloning would harm it.

          Embarassed about the tech detail

  • Hmm (Score:5, Interesting)

    by GigsVT ( 208848 ) on Thursday July 24, 2003 @11:45PM (#6529082) Journal
    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 :)

  • 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 abstract

    • Re:Driver complexity is the tricky point (Score:5, Insightful)

      by Anonymous Coward on Friday July 25, 2003 @01:07AM (#6529495)
      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.

      • Writing drivers for windows has gotten so complex the Microsoft is working on a new driver framework called the "Windows Driver Framework" to try and simplify it and to get more robust drivers from 3rd party developers. You can read an introductory article here [wd-3.com] by Walter Oney... it is very enlightening and highlights the various issues that a driver writer has to know at a very deep level to write even the simplest driver these days.

  • New platforms come at a fraction of the cost. (Score:5, Insightful)

    by aminorex ( 141494 ) on Friday July 25, 2003 @01:15AM (#6529528) Homepage Journal
    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.

    • Re:New platforms come at a fraction of the cost. (Score:4, Interesting)

      by spitzak ( 4019 ) on Friday July 25, 2003 @01:44AM (#6529642) Homepage
      If you release it GPL (or any other open-source compatable license) and your first version works at all (it does not crash & it manages to communicate enough signals that at least a light blinks & it contains enough partially-working code to "document" the device) then I would estimate the maintenence costs by multiplying them by zero. The driver would be immediately added to the Linux source and debugged and improved by users of your device. You would probably also make a bunch of sales instantly.

      The only downside is that legally you cannot take fixes made by those outside users and put them into your closed-source drivers. However it is highly likely that you can ask the authors of the changes for permission to use the code, one way to convince them is to say that doing that is the only way for their code to get into the "official linux driver" that can be downloaded from your web page.

      • Re:New platforms come at a fraction of the cost. (Score:5, Insightful)

        by TephX ( 54484 ) on Friday July 25, 2003 @08:21AM (#6530748) Homepage
        The only downside is that legally you cannot take fixes made by those outside users and put them into your closed-source drivers. However it is highly likely that you can ask the authors of the changes for permission to use the code, one way to convince them is to say that doing that is the only way for their code to get into the "official linux driver" that can be downloaded from your web page.

        Or just release your Windows drivers under the GPL. I mean, if you're releasing GPL Linux drivers anyway, then you're clearly not protecting any proprietary interface information or whatnot, and drivers are hardly an item on which you can make a profit by selling them anyway, so it really seems like you don't lose anything at all by GPLing the Windows drivers too.

        Yeah, this is "not the way it's done" and the managers won't agree to it. My point isn't necessarily that this is realistic, but that the people opposed to it are just being stupid.

        • True that may help a lot as improvements to the Linux driver can then also be put into the Windows driver. Thus you could make a reasonable claim that maintinence costs of the Linux driver are actually negative.

          What I meant, which may still apply, is that you cannot change your mind and make your drivers (either the Windows or Linux ones) closed-source without either removing all the donated changes or getting permission to all the donated changes.

          I'm also under the impression that open-source Windows d

    • Re:New platforms come at a fraction of the cost. (Score:5, Insightful)

      by sigxcpu ( 456479 ) on Friday July 25, 2003 @02:22AM (#6529799)
      You should also cinsider the fact, that debugging device drivers under Linux, is much easier then under windows, because you have the source of the OS, and if you suspect that there is a bug, you can add your debug code wherever you want and test it. (sometimes much faster then reading the code and trying to find it - something you can't do in windoze anywhay.)

      One company I worked for even developed a linux deriver, it had no intention of officialy releasing, (It was just one part of a bigger device) just to get the ability to debug the the hardware efficiantly.

      (Yes I am a linux kernel programmer.)

      Besides, if your devieces are usefull, the Linux comunity has an intrest in having them work under linux.
      If your device is something of common use, say an IDE controller or a NIC, you would find people willing to help you, or even write the driver for you, if you provid the full documantation and a working sample. (and if you give them a peek at the sources of your working windows driver it will probably be a very simple job. )
      If you are willing to supply these then the right place to ask is on the LKML.

  • WinDriver (Score:3, Interesting)

    by Twylite ( 234238 ) <twylite&crypt,co,za> on Friday July 25, 2003 @02:59AM (#6529900) Homepage

    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 [jungo.com] (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.

    • Re:WinDriver (Score:2, Insightful)

      by Anonymous Coward
      Maybe, but what kind of performance cost are you facing? And how are any 3rd parties meant to maintain the driver then?

      • Third parties aren't meant to maintain the driver. Performance isn't an issue for USB 1.1 (maybe for USB 2.0, depending on the device), and you're talking about a company that specialises in creating device drivers -- their collective knowledge of performance and stability issues almost certain outweighs what can be achieved by a non-dedicated (to driver development) individual or team.

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

  • definitely a 1 or 2, no higher (Score:4, Insightful)

    by itzdandy ( 183397 ) on Friday July 25, 2003 @06:12AM (#6530382) Homepage
    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.
  • 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?
  • 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 ... our boss is kind of convinced that this might sell some more units,

    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 incre
    • You are not warning against the GPL here, if I understand you correctly, but about opening the device driver source to outside eyes.
      Personally, I never understood how a hardware API would need to give away too much about the hardware itself, but I guess it depends a bit on the hardware itself.
      Then again, if someone wants to clone your hardware, and thinks it will help to have your device driver, they can always decompile the source code and read it (it will take a lot more effort, but that will probably no

      • Re:Same difficulty as Windows (Score:1, Interesting)

        by Anonymous Coward
        ....I never understood how a hardware API would need to give away too much about the hardware itself, ....

        Depends on how much is in the hardware. If the hardware is a bunch of little functional units that are bound together in the driver then you can give away lots. If the hardware is opaque and mega-lithic then you don't give away so much.

    • Although generally desirable, there is no requirement that third-party kernel modules (which I assume would be the primary form your driver the driver would assume) be released under the GPL. Thus, being forced to GPL IP you consider valuable is not an issue.
    • This is true. I personally think that the GPL is an excellent idea, and one of the best things that's happened to software in the past ten years.

      However.

      You do have to look at the future of your product.
      Are you the sole supplier of this product? If so, then you may wish to hold on to your code and specifications and attempt to corner the market.

      On the third hand, if you are the sole supplier of this product, it may well behoove you to release the source code for the drivers. This might encourage
  • 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.

  • how about OS X? (Score:3, Insightful)

    by The Lynxpro ( 657990 ) <[moc.liamg] [ta] [orpxnyl]> on Friday July 25, 2003 @11:55AM (#6532570)
    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...
  • 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...
  • I'd imagint that there would be some common code between windows and Linux. That would have to be GPL or out of kernel. I have no problem with binary drivers in my kernel, but some people consider it tainting the kernel. How much IP are you willing to give away under the GPL is what this boild down to?

    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/device

  • 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 l
  • 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.

Slashdot Top Deals

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Close