Slashdot Mirror
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.
Binary only does not automatically mean buggy code. Not everything that comes our of a for profit, non-open source business is crap. Yes, it means you can't see the code and fix it yourself. By the same token, the consumer is all powerful. Don't use it if it doesn't work. Tell the manufacturer. Most companies try to fix problems with their code because they want to keep you as customers. MS is one of the few companies that is so powerful that they can afford to ignore bugs in their code. They are the minority, though. Most companies that make buggy code and never fix it go out of business.
Excepting binary only programs and drivers will allow companies that would normally not provide Linux software into it. I know the lack of binary only exceptance is a big reason why many firms don't get into porting their code to Linux. They think that they have to publish the source and they really can't. So you can't use their really cool scanner under Linux. I think that the more support we have, the better.
-- soldack
Is this the first posted tutorial??
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".
"Oh, I hope he doesn't give us halyatchkies," said Heinrich.
Yeah. I also didn't like the "everything is a file" section on the first page--IMHO it analogizes Windows/DOS/Mac drivers, which are files containing binary code, with /dev entries, which are not. Not a useful analogy, and potentially confusing.
/.ed...
The rest is accurate and decently writeen, if basic (which is fine).
It's also heavily
-Doug
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.
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.
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
True that. I thought they were saying that in MacOS, as in Linux, you open the special files and then read and write data to that file. But after looking at it again, it sounds more like /dev contains all the binary drivers that run your hardware.
/dev/Deskjet 792! how do I print?" and "wtf? ls /dev/fd0 doesn't give me the files on the diskette? linux sux!" I think there should be some kind of statement warning people that actually treating the files in /dev as normal files to be accessed by the user is NOT RECOMMENDED!
I don't know why they're trying to compare the two, as things are completely different.
Finally, I can see people complaining that "there's no
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
I think linux teaches you what you need to solve the problems you see as you go. Only in the last week did I learn about XF86Setup!! Sorry for the off-topic bit, I'm just defending myself as a 'pure newbie' who's used linux more than a week, but didn't know some of the utilities mentioned in the parent post. (I haven't read the article, though).
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".
314-15-9265
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.
.sig: Now legally binding!
Unless you want Linux to be as flakey as Windows, and drivers to be a security rick and kernel-specific and hence preventing you from upgrading to a new kernel whenever you want, and unless you want to wait several months for a bug to be accepted as such by the manufacturer, and more months until a fixed version is released.
Who's side are you on?
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Not everyone is an open source hacker. Many of us have jobs at corporations that say no when we ask about porting drivers to Linux because they feel there isn't enough documentation and that it would cost too much money. Your comment about not having information on hardware doesn't make any sense here. Writing device drivers doesn't have to be hard. Saying that it does is giving up. Writing an OS from scratch is hard but Linus had his Operating Systems book with all the Minux source and information. I used that book for my operating systems class and it is pretty long but I bet Linus was thankful for it (I know I was). Making things easier is a good thing. You shouldn't have to be a master hacker to write a device driver. You shouldn't have to work from scratch after someone else already figured it out. The easier it is to write software for Linux the higher the quantity and the quality of Linux software will be.
-- soldack
Still it's Linux documentation and anyone who writes this stuff deserves praise - but please fill it out a bit! Maybe turn it into a HOWTO?
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).
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:
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
This is a little offtopic, but could anyone recommend some good reading material on *writing* device drivers? Is the O'Reilly book any good?
I'm going to attempt to code a driver for the "IBM Wireless LAN Entry" PCMCIA card. Is anyone else working on a driver for this device? I really think a driver for this is needed since these cards are only selling at about $30 *tops* now and will do about 350k/s.
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.
pb Reply or e-mail; don't vaguely moderate.
How many many of these books have you seen?
/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.
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
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
If you look at the bottom of the sidebar, there is a link called "Rent E-mail Lists". Sure enough they will rent you lists for $0.10 a address. Minimum of 4,000 addresses. I guess this is the cost of Linux going main stream. And being embraced by the get rich quick suites. I guess linuxplanet is an example of what happens when a linux site joins a "network". Watered down newbe content and abandonment of internet principles for greed. humm... Run Rob Run ... Save your sole while you still can.
How does this fit in with regular Slashdot fare?
Whoever needs such material will find it at the proper sites (from which it should be linked). Are you going to start featuring rc-script customization next?
khg.redhat.com