Tutorial on Linux Device Drivers

vorsprung directed my attention span of a gnat to Linux Device Drivers Demystified, an interesting tutorial giving an overview of Linux device drivers (No kidding). As well, they've got devtective, a search facility to check any (Surprise!) devices you want to check to see if they are supported currently. Lastly, for those of you who really want to get into it, read the review of Linux Device Drivers.

Comments

Informative, but the title's a little misleading

[arthurs_sidekick]

Nothing in here I didn't already know, and I am far from an expert. I thought from the title it might have info on how to *write* drivers (the O'Reilly book's probably a bit long in the tooth by now, correct me if I'm wrong about that).

None of this is to take away from the article itself; it was well written, and you shouldn't try to compile your own kernel without knowing what it tells you.

It should probably have been called a "Primer" instead of a "tutorial".

Actually, the O'Reilly is fine

[sleeping wolf]

I have a copy of it. It's still almost completely applicable. Most of what you need to know hasn't changed.

Furthermore, I would recommend it wholeheartedly. The examples cover what you need, but are simple enough to pick up quickly. With this book I picked up writing device drivers within a day.

Re:Actually, the O'Reilly is fine

[terjegj]

Rubini's book is mostly about kernel version 2.0. Some of the examples don't work out of the box, but reading Richard Gooch's Kernel API changes from 2.0 to 2.2 might help.

Misleading.

[Mr. Piccolo]

The title should be something like "The Linux _Kernel_ Device Driver Tutorial (Guide?)".

That, of course, is what it actually covers. In other words, if you're searching for the latest OpenGL drivers for 3DLabs video cards, you'll be sorely disappointed. Ditto if you want to find the ALSA homepage.

If it ain't in the kernel, it ain't going to be in their search engine either.

Oreilly Book

[Eric Seppanen]

When I asked O'Reilly in July about a new revision of Rubini's book, they told me that he wasn't doing the next revision and they were in search of somebody to do it.

I really wish that a 2.2 version of the book was available. It sucks having to second-guess everything you read: "the book says foo. Guess I better go hunt on the web for a while to see if that's still the case".

A little too 'newbie'.

[technos]

Frankly, I was disappointed as soon as I saw the introduction. I suppose the parallel to the O'Reilly book fooled me, but the title was way too ambitious. Still, a fine read for those new(er) to *nix. I'm mailing out the link to a few of the guys here and reading it will be enforced. We had a 'cat stuff > /dev/fd0' debacle last week, resulting in a half a dozen calls to me asking to retrieve their file so they could open it up in Word.

What's really needed...

[edhall]

What's really needed is something that an engineer at a random hardware manufacturer can pick up and run with--not so much the why or even the what of Linux devices drivers as the how. Although Linux Device Drivers is a good start, it's getting a little long in the tooth and will rapidly get outdated with some of the resource management changes that will appear in 2.4 (and are already in the development 2.3 version). New device types like USB (a whole suite of issues here), video capture, and so on, need to be treated, along with better coverage of issues like the SCSI interface.

Ideally, all an engineer should need to do is find a driver for the device most similar to his/her new device, and follow some general steps in indentifying and making the necessary adaptations. In a perfect world, the engineer would understand the Linux kernel inside and out, but chances are he/she will be completely Linux-ignorant, and will have a matter of a few weeks in which to produce the driver. Thus it would be helpful to draw parallels to Windows drivers (which are likely to be already available or at least more familiar to the engineer), and perhaps cookbook methods for translating them for Linux. Put a limit on theory, history, and other details that don't help the engineer get the job done, fast.

I know that this attitude might be a bit controversial, but in the real world, non- support for a prefered device is a frequent show-stopper for Linux. Let the open-source community work on making the drivers work well--but there has to be a driver in the first place.

Let's hope Alessandro Rubini, or someone of his knowledge and abilities, can produce such a book. It's one of the more crucial issues blocking Linux World Domination(tm).

-Ed

New Revision of Device Driver Book Needed

[Amoeba Protozoa]

I own the "Linux Device Drivers" by Alessandro Rubini. It is a good book for learning the (somewhat) confusing driver interface under Linux. However, I think a new revision of this book is needed to address things like:

• Operating within an SMP environment.
• Programming to the new APIs, such as:
• ISDN4Linux
• Video4Linux
• I2O
• Dare I say, USB
• Insert your favorite new API here.

Tuning your device drivers; specific hints for character drivers, block drivers, and net drivers.

A special section devoted to writing and maintaining a kernel version independant, mostly binary, device driver (for more closed companies). This could yield a wider base of companies that support Linux, as they don't want to, "give away the family jewels."

What we need is the definitive guide. A portable, referrable, assemblance of all Linux device driver knowledge to promote the growth and acceptance of Linux as an O/S in the buisness and even the hobbiest communities. Such a book would also raise the bar for performance within the average driver-- something which would help Linux win those benchmark tests. To support this argument, approach your favorite monolithic hardware manufacturer and ask him what tools they are using to support Linux into the future. If they answer with:

• "I don't know."
• "We have an older book to refer to."
• or, "A collection of websites."

You can see there is a definite need. I would hope that Alan Cox and Donald Becker would be contributing authors.

If I could write, and could write good enough driver code, I would do it myself.

-AP

Re:New Revision of Device Driver Book Needed

[soldack]

As someone who is working on device drivers under NT and will be soon porting them to Linux, I agree with the first post. More documentation is needed. Your response of, "If you can't hack at it and make it work, you shouldn't be doing it!" is absurd. If someone spends hours figuring out how to do something they should tell everybody so others do not have to go through the agony. That is the responsible and friendly thing to do. Teamwork and collaboration make development go faster and are big part of the reason Open Source Software is moving up in the world. With your type of attitude no one would no Linux but Linus and few others. Do you think that Donald Becker doesn't help out people trying to write NIC drivers? I can't imagine him saying, "Go figure it yourself and if you can't you shouldn't be doing it."

As for a big book....most programmers I know love having a big fat reference manual. You don't read them, you search for what you need when you need it. The i2o spec is massive but I couldn't get anything working without it.

I don't like MS but by publishing a lot of information on their APIs they make it easy for developers to write for them. This attracts business and other users.

Ignore this article...

[pb]

This might be more appropriate for people using one particular distribution that don't want to know the details. (i.e. most newbies / Windows users / journalists :) The *Using* Device Drivers section is pretty simplistic, and the search facility is neat, but nothing you wouldn't see by running 'make menuconfig' or something.

So... read this if (a) you don't know what a kernel is (b) the idea of recompiling it scares you (c) you just want to use your distribution, and not know where it came from. Anyone else, just ignore it.

The Linux community demands the wrong thing!!!

[segmond]

How many many of these books have you seen?

Solaris Device Drivers
AIX Device Drivers
*BSD Device Drivers
HPUX Device Drivers
Windows Device Drivers

Not many I guess, Do you know why? Because not everyone hacks device drivers. Yet the linux community has one, and is whining whining. If you can't start out with that, you are not cut out for the job, please go back to your PERL scripts. The problem we have today with hacking device drivers it not that they are hard to code, but rather lack of information on the hardware! Thats right, What device on earth do you think we can't hack a driver for? Having a 10000 page manual on hacking device driver is useless if companies will not release information on hardwares. So rather than stay here and ramble on books, why don't we all /mail companies and tell them we love Linux and would love their device supported on it? If they don't have a competent engineer, we the Linux community will provide a competent hacker. If they don't want information out on their hardware to protect their products, we will sign the NDA, but we just want their drive on our box.