How to write a Linux device driver | Hacker News Reader

How to write a Linux device driver

freesoftwaremagazine.com

161 pointsrohshall21 comments

VFIO!

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.

No, 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.

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

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

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

Interrupts are the slowest part of VFIO, but everything else is comparable. The interrupt performance can and will be fixed in the future. Polling is an option for some network uses, but interrupts are obviously technically superior for most workloads.

The I/O MMU can be slightly slower than "true" DMA if done poorly, but the simple use case is actually performs the best (in my teeny experience).

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

It'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.

What do you mean by 'specialist debug hardware'?

Basically, one of these:

http://en.wikipedia.org/wiki/Bus_analyzer

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

The "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). 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!

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

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

I did it two places. Both were full time

Cable set top boxes often use Linux, and often need drivers.

Has much changed for 3.0?

No.

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/

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

Thanks for the post. I tend to write python to talk to custom USB devices, but this looks like a nice alternative.

Can you elaborate? I specifically have a couple USB devices I need to work with and thought I would have to write a device driver for them :)

http://sourceforge.net/apps/trac/pyusb/

Reply on news.ycombinator.com