5 ms·
How to write a Linux device driver
- ChuckMcM 14y agoThey missed the part where you need documentation on how the chip used in the I/O device actually works. This is the 'tricky' bit way to often.
- pmjordan 14y agoIt's not too bad if the device uses USB and you have a working Windows driver for it: run Windows in a virtual machine on Linux, pass the USB device through to it and log the traffic using Linux' USB debug facility. Then figure out what that traffic means. It depends on the device how difficult this is, but for simpler devices it's actually quite straightforward. For other types of devices or if you don't have ANY driver, it's obviously somewhat trickier, as most I/O protocols are a lot lower level than USB (the host controller driver takes care of most of the heavy lifting for USB). I suspect you'll need specialist debug hardware to log the generated traffic.
- shurane 14y agoWhat do you mean by 'specialist debug hardware'?
- pmjordan 14y agoBasically, one of these: http://en.wikipedia.org/wiki/Bus_analyzer http://en.wikipedia.org/wiki/Bus_analyzer
- deleted 14y ago[deleted]
- ChuckMcM 14y agoUSB is pretty easy in that regard, you can do the same with a PCI bus analyzer but they are a bit more expensive. However, and I'm sure you are aware, doing so is expressly forbidden by the DMCA under the 'reverse engineering' clause. Not many folks have been pursued by this in the driver space but you need only see how nutso Microsoft went over people 'reverse engineering' Kinect to see how it goes down.
- schoen 14y agoThe "reverse engineering" clause of the DMCA protects reverse engineering, rather than forbidding it. Take a look at 17 USC §1201(f) (http://www.law.cornell.edu/uscode/text/17/1201#f http://www.law.cornell.edu/uscode/text/17/1201#f). The DMCA only applies in the first place if a "technological measure" "in the ordinary course of its operation" "effectively controls access to a work", which needn't always be the case for reverse engineering. The idea that the DMCA expressly forbids reverse engineering is a misconception. Microsoft eventually changed its position on Kinect and never filed a lawsuit over the reverse engineering. So, we don't have a court decision suggesting that there was anything legally improper in any way about the Kinect reverse engineering. Hackers should be upset about §1201 and speak out against it, but not be gratuitously scared off from doing things!
- gte910h 14y agoThis isn't half bad. (From someone who did this for a living at one point) Btw, if you're writing a USB driver, most of the time the device uses HID, even though that's for a completely different type of device then what HID is supposed to be specced for.
- pmjordan 14y ago"From someone who did this for a living at one point" I'm curious: was this as an independent contractor or for an established company? I really enjoy driver programming and low level stuff for some reason (OSX & Linux and game consoles so far) and would rather like to specialise my contract work on that kind of thing. Beyond people stumbling across my work online, I really don't know who to approach and where to look for that kind of work. It's rather a lot easier to get referrals for more mainstream development work.
- gte910h 14y agoI did it two places. Both were full time Cable set top boxes often use Linux, and often need drivers.
- chris_wot 14y agoHas much changed for 3.0?
- spartango 14y agoNo. Keep in mind that the 2.6.x -> 3.0 transition was largely just in the version numbers...in terms of the code there was no major overhaul or change. ref: http://lkml.org/lkml/2011/5/29/204/ http://lkml.org/lkml/2011/5/29/204/
- ajross 14y agoIt was entirely just the version numbers. 3.0.0 is what 2.6.40 would have been; there were no meaningful process changes in that release, and the list of new features was entirely in keeping with all the other recent releases. They simply popped a minor version number off the stack for simplicity.
- codemac 14y agoVFIO! The I/O MMU! Write your drivers in userspace, save your sanity. I realize it's hard to get a kernel that supports everything you need to accomplish this, but it's definitely "the future" when it comes to device drivers. However, this is a decent beginning point for people completely unfamiliar with writing a driver. The table and the makefile parts are especially important for beginners to just get freaking started.
- nitrogen 14y agoNo, don't write your drivers in user space. Especially for low-latency devices, all the user-kernel-user message passing will be problematic. You can't run at interrupt priority in user space, either.
- jrockway 14y agoMost devices are USB dongles that flash lights and shift a couple bits, not 100Gbps network cards. It follows that most people's needs will be met by a Python script and libusb, rather than a kernel module.
- lukego 14y agoI agree that kernel-space drivers are a relic of the 20th century. You can write fast network card drivers in userspace too. You map the physical DMA memory into userspace and cut out the kernel entirely. Interrupts don't even come into the picture when you're polling several packets per microsecond. Lots of those cards nowadays come with high-end packet I/O libraries that are implemented in userspace. Myricom Sniffer10G, Intel Data Plane Development Kit, ntop.org DNA, etc.
- nitrogen 14y agoI suppose. I speak from the limited experience of reverse engineering a driver for a PCI device that would freeze the entire system if its interrupts weren't acknowledged immediately.
- 14y ago
- Tequals0 14y agoThanks for the post. I tend to write python to talk to custom USB devices, but this looks like a nice alternative.