Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Tutorial on Linux Device Drivers 29

Posted by Hemos from the but-it-still-won't-explain-winmodems dept.
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.
This discussion has been archived. No new comments can be posted.

Tutorial on Linux Device Drivers More

Tutorial on Linux Device Drivers

Comments Filter:
  • 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.

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

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

    The rest is accurate and decently writeen, if basic (which is fine).

    It's also heavily /.ed...

    -Doug

  • Actually, the O'Reilly is fine (Score:3)

    by sleeping wolf ( 1671 ) on Thursday September 23, 1999 @09:46AM (#1663789) Homepage
    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.

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

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

  • Re:Actually, the O'Reilly is fine (Score:3)

    by terjegj ( 29900 ) <terjegj.hotmail@com> on Thursday September 23, 1999 @10:07AM (#1663792)
    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 [csiro.au] might help.
  • Actually, it's not redundant. Some device drivers for Linux are part of the kernel distribution (eg., it's inside linux-2.2.12.tar.bz2 and will be found by their search engine), and some of the device drivers are not - such as all the video card drivers in XFree86 (which they do have a link to, at least), video card drivers not yet in XFree86, support for brand new ethernet card variations (that people like Donald Becker will have available seperately, but haven't made it into the kernel yet), OSS Commercial sound drivers and ALSA sound drivers to name some.

    For real cutting-edge stuff that you can't find in their search engine, a look at the Hardware Compatibility HOWTO, a search of www.deja.com for something like "Linux 3COM OfficeConnect", or a specific HOWTO like the Ethernet HOWTO would help.

  • Oreilly Book (Score:3)

    by Eric Seppanen ( 79060 ) on Thursday September 23, 1999 @11:09AM (#1663795)
    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".
  • 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.
  • 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?
  • 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.
  • A little bit basic :-) If you've been using Linux for a while you will already know this and if you're a newbie you will have already looked elsewhere.

    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?

  • What's really needed... (Score:4)

    by edhall ( 10025 ) <slashdot@weirdnoise.com> on Thursday September 23, 1999 @11:48AM (#1663800) Homepage
    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 [amazon.com] 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

  • I own the "Linux Device Drivers" by Alessandro Rubini [amazon.com]. 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:

    You can see there is a definite need. I would hope that Alan Cox [linux.org] and Donald Becker [nasa.gov] would be contributing authors.

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

    -AP

  • Recommendations? (Score:1)

    by Anonymous Coward
    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.
  • I totally disagree with you. I agree that revision is needed, but not in the manner which you suggest. Writing device driver is not BASIC programming. It is not something for people with no brain to do. Asking for a definitive guide is crazy. As someone who hacks driver, you should be able to figure out things for yourself. Asking for API as ISDN4Linux and Video4Linux is really nuts. Tomorrow you will be asking for Audio4Linux, ADSL4Linux, CableModem4Linux ... Seriously, if you can't figure that out by reading your book and looking at the existing sources, then you are not cut out to be writing drivers. USB is not a bad idea, as there is not many info on it.

    Device drivers are complex, and when it comes to hardware and lowlevel stuff. There is never going to be a definitive guide, because hardwares and low level stuff change at an alarming rate and vary on different systems. The purpose of the book is to start you out on your path to device driver hacking. It shows you the basic ideas, and you figure out the rest. The reason companies are not writing drivers is not because of lack of adequate documentation, but rather because they don't seen any profit, yet. I mean, what you are asking for is a device drivers BIBLE, the truth is that such stuff will be obsolete in 2 years, and it will take 3 years to write. It will also be much more complicated for newbies to grab.

    Can you imagine grabbing a 2000 page book on coding device drivers? Holy Smoke, I do shit my pants if someone gave me such stuff to read. A 100-200 page book which is quite, concise and very clear is what is needed. "Linux Device Drivers" does that, it just needs to be updated often, hopefully online wise, because I definitely can't afford to buy a new version every year.

  • Ignore this article... (Score:3)

    by pb ( 1020 ) on Thursday September 23, 1999 @10:18AM (#1663804)
    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!!! (Score:3)

    by segmond ( 34052 ) on Friday September 24, 1999 @03:00AM (#1663805)
    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.

  • I have a simple question to ask of you:

    Would you rather have support for a piece of hardware, broadening the support-base and encouraging the poliferation of an O/S, or not?

    Currently, there are a lot of companies that ship binary only drivers for other operating systems. In Linux you have more of a choice than you do under other closed-sourced O/Ss. Understand that you could decide between the vendor's that ship open-source and closed-source drivers. Althought I would prefer an open-sourced driver, I certainly would not deny the extra choices presented by a few closed-source ones.

    To make another point, there is plenty of code that is used with the Linux kernel that is closed source. Some hardware manufacturers distribute binary-only firmware packages along side their driver. They implement a bare-bones open(), read(), write(), seek(), and a few ioctl() routines that nearly act just as wrappers to some logic down at the board level. Why would manufacturers do this?

    • To make the O/S level interface as slim as possible, this greatly increasing the number of operating systems they can potentially support easily.
    • To make an extremely complicated product less complicated on the host O/S, thereby freeing up host CPU time.
    • To hide from you, "the family jewels."

    Who's side am I on? Well, I would have to say mine. I think that Linux is nice and all: but I pick the O/S that pays the bills. If a customer wans NT, Solaris, SCO, or Linux: I will give them what they want. I think of Linux as I think of a screw-driver: just another tool in my toolbox.

    -AP

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

  • Yes, I am acutally asking for hard documentation for the Linux APIs. This is not an absurd request.

    There is never going to be a definitive guide, because hardwares and low level stuff change at an alarming rate and vary on different systems.

    Has the PCI spec changed dramatically in the last 3+ years? Sure it has been revised, but not enough to greatly affect driver code! I am not interested in hacking out a driver, I am interested in coding one, professionally, for my company. Yes, my company (as wrong as it is) decided not to author Linux device drivers becuase of a lack of documentation and a high learning curve. This is changing.

    I can imagine a 2000 page book. I have seen simular books on algorithms. I have seen simular books about plants, war, or birds. Size does not matter.

    -AP

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

    Heh, these days my favorite companies are the ones who produce devices which have Linux drivers readily available. Since I can now find Linux-compatable drivers for most classes of devices, I don't worry about this stuff too much anymore.

  • khg.redhat.com
  • 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.

Slashdot Top Deals

C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup

Close