Linux Device Drivers

( 1 )

Overview

This book is for anyone who wants to support computer peripherals under the Linux operating system or who wants to develop new hardware and run it under Linux. Linux is the fastest-growing segment of the Unix market, is winning over enthusiastic adherents in many application areas, and is being viewed more and more as a good platform for embedded systems. Linux Device Drivers, already a classic in its second edition, reveals information that heretofore has been shared by word of mouth or in cryptic source code ...

See more details below
Available through our Marketplace sellers.
Other sellers (Paperback)
  • All (18) from $1.99   
  • New (3) from $19.44   
  • Used (15) from $1.99   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$19.44
Seller since 2008

Feedback rating:

(169)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
0596000081 BRAND NEW NEVER USED IN STOCK 125,000+ HAPPY CUSTOMERS SHIP EVERY DAY WITH FREE TRACKING NUMBER

Ships from: fallbrook, CA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
$22.07
Seller since 2009

Feedback rating:

(856)

Condition: New
0596000081 *BRAND NEW* Ships Same Day or Next!

Ships from: Springfield, VA

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$50.00
Seller since 2014

Feedback rating:

(149)

Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Close
Sort by
Linux Device Drivers

Available on NOOK devices and apps  
  • NOOK Devices
  • NOOK HD/HD+ Tablet
  • NOOK
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac
  • NOOK Study
  • NOOK for Web

Want a NOOK? Explore Now

NOOK Book (eBook)
$17.99
BN.com price
(Save 43%)$31.99 List Price
This digital version does not exactly match the physical book displayed here.

Overview

This book is for anyone who wants to support computer peripherals under the Linux operating system or who wants to develop new hardware and run it under Linux. Linux is the fastest-growing segment of the Unix market, is winning over enthusiastic adherents in many application areas, and is being viewed more and more as a good platform for embedded systems. Linux Device Drivers, already a classic in its second edition, reveals information that heretofore has been shared by word of mouth or in cryptic source code comments, on how to write drivers for a wide range of devices.

Version 2.4 of the Linux kernel includes significant changes to device drivers, simplifying many activities, but providing subtle new features that can make a driver both more efficient and more flexible. The second edition of this book thoroughly covers these changes, as well as new processors and buses.

You don't have to be a kernel hacker to understand and enjoy this book; all you need is an understanding of C and some background in Unix system calls. You'll learn how to write drivers for character devices, block devices, and network interfaces, guided by full-featured examples that you can compile and run without special hardware. Major changes in the second edition include discussions of symmetric multiprocessing (SMP) and locking, new CPUs, and recently supported buses. For those who are curious about how an operating system does its job, this book provides insights into address spaces, asynchronous events, and I/O.

Portability is a major concern in the text. The book is centered on version 2.4, but includes information for kernels back to 2.0 where feasible. Linux Device Driver also shows how to maximize portability among hardware platforms; examples were tested on IA32 (PC) and IA64, PowerPC, SPARC and SPARC64, Alpha, ARM, and MIPS.

Contents include:

  • Building a driver and loading modules
  • Complete character, block, and network drivers
  • Debugging a driver
  • Timing
  • Handling symmetric multiprocessing (SMP) systems
  • Memory management and DMA
  • Interrupts
  • Portability issues
  • Peripheral Component Interconnect (PCI)


"We're back to the times when men were men and wrote their own device drivers." -- Linus Torvalds. Of course, this is also a very good publication for the excellent, equally facile (and less macho) kernel and hardware programmers of the opposite gender. Comments aside, this is a very good (and to-date the only publication) for programmers and developers that covers device drivers in-depth. The author assumes that you understand the Linux kernel and C code.

Read More Show Less

Editorial Reviews

From Barnes & Noble
The Barnes & Noble Review
There are a world of devices just waiting to have Linux devices written for them, and a world of users who will be forever grateful if you take on the quest. It's a quest that'll take you deep inside the bowels of the Linux kernel -- and offer powerful psychic rewards when you succeed. Take this guide on your journey: Linux Device Drivers, Second Edition.

Alessandro Rubini and Jonathan Corbet have done an excellent job of getting their arms around this very big subject. They first introduce modularization and what it means for modules to run in kernel space rather than user space. (Those who've built device drivers for Windows NT will recognize this distinction.)

You'll learn how to set up kernel modules properly, avoiding header files and eschewing namespace pollution (remember, even the smallest kernel module links to the entire kernel, and can wreak havoc if you're not careful). You'll also learn how modules use system resources such as memory, I/O ports, and IRQs.

By Chapter 3, you're writing a complete character device driver -- which is all that some simple hardware devices will need. To illuminate the techniques they present, Rubini and Corbet draw upon examples from scull, the Linux Simple Character Utility for Loading Localities (which, in essence, treats an area of memory as if it were a device). They introduce file operations and struct files, and introduce the problem of race conditions (a classic problem with device drivers which will get much deeper consideration later in the book).

Once you've learned how to provide for read and write operations, you'll learn how to perform a variety of hardware control tasks using ioctl, a device-specific entry point for the driver to handle commands. The authors warn you about some gotchas you might otherwise not notice -- gotchas related to numbering your commands, and working with pointers to user space.

Real-world drivers need to pay especially careful attention to timing. Linux Device Drivers contains a full chapter on the topic. It introduces the timer interrupt, shows how to retrieve the current time, how to delay execution of a piece of code for a specified amount of time (to give the hardware time to finish what it's doing); and how to schedule functions using task queues, tasklets, and kernel timers.

Early in the book, Rubini and Corbet introduce debugging -- a special challenge when it comes to device drivers, which don't lend themselves to easy execution or tracing by a debugger. (It doesn't help that Linus dislikes interactive debuggers almost as much as he likes penguins, and won't build one in.) Your options include debugging by printing (using printk); by querying; and by watching. If you still can't track a bug down, you can at least collect information about its behavior when it generates a system fault.

There's a short but extremely valuable chapter on portability. The Linux kernel is extremely portable, but you have to watch out for your data typing, and be suspicious of explicit constant values (if you've lived your life in the x86 universe, you may find time intervals, page sizes, and byte order to be especially problematic).

From start to finish, each chapter of Linux Device Drivers covers a single problem; for example, getting hold of memory, managing I/O, handling interrupts. Part II moves on to block drivers, network drivers, peripheral buses, and finally, a quick look at the layout of kernel source. (The book's written for the 2.4 kernel but also covers 2.2, and offers some workarounds for 2.0. Throughout, the authors call your attention to significant changes in the latest kernels, including changes to resource management, wait queues, and the block device layer, to name a few examples.)

Rubini and Corbet won't completely absolve you from grepping through kernel sources, but they've done a lot of that work for you. You'll still need to join the Linux-kernel mailing list, but hey: you'll understand what they're talking about! (Bill Camarda)

Bill Camarda is a consultant, writer, and web/multimedia content developer with nearly 20 years' experience in helping technology companies deploy and market advanced software, computing, and networking products and services. His 15 books include Special Edition Using Word 2000 and Upgrading & Fixing Networks For Dummies®, Second Edition.

Read More Show Less

Product Details

  • ISBN-13: 9780596000080
  • Publisher: O'Reilly Media, Incorporated
  • Publication date: 7/2/2001
  • Edition description: Second Edition
  • Edition number: 2
  • Pages: 592
  • Product dimensions: 7.12 (w) x 9.22 (h) x 1.15 (d)

Meet the Author

Jonathan Corbet got his first look at the BSD Unix source back in 1981, when an instructor at the University of Colorado let him "fix" the paging algorithm. He has been digging around inside every system he could get his hands on ever since, working on drivers for VAX, Sun, Ardent, and x86 systems on the way. He got his first Linux system in 1993, and has never looked back. Mr. Corbet is the co-founder and executive editor of Linux Weekly News; he lives in Boulder, Colorado with his wife and two children.

Alessandro Rubini installed Linux 0.99.14 soon after getting his degree as an electronic engineer. He then received a Ph.D in computer science at the University of Pavia despite his aversion toward modern technology. Alas, he still enjoys digging in technology and discovering the intelligence of people who created it: that's why he now works in his apartment with three PCs, an Alpha, a SPARC, and an Apple2 — the last without Linux. But you might find him roaming around in the north of Italy on his bike, which doesn't carry an electronic cyclometer.

Read More Show Less

Read an Excerpt


Chapter One: An Introduction to the Linux Kernel

People all around the world are delving into the Linux kernel, mostly to write device drivers. While each driver is different, and you have to know your specific device, many principles and basic techniques are the same om one driver to another. In this book, you'll learn to write your own device drivers and to hack around in related parts of the kernel. This book covers device-independent programming techniques, without binding the examples to any specific device.

This chapter doesn't actually get into writing code. However, I'm going to introduce some background concepts about the Linux kernel that you'll be glad you know later, when we do launch into writing code.

As you learn to write drivers, you will find out a lot about the Linux kernel in general; this may help you understand how your machine works and why things aren't always as fast as you expect or don't do quite what you want. We'll introduce new ideas smoothly, starting off with very simple drivers and building upon them; every new concept will be accompanied by sample code that doesn't need special hardware to be tested.

The Role of the Driver Writer

As a programmer, you will be able to make your own choices about your driver, choosing an acceptable tradeoff between the programming time required and the flexibility of the result. Though it may appear strange to say that a driver is "flexible," I like this word because it emphasizes that the role of a device driver is providing mechanisms, not policies.

The distinction between mechanism and policy is one of the best ideas behind the Unix design. Most programming problems can indeed be split into two parts: "what needs to be done" (the mechanism) and "how can the program be used" (the policy). If the two issues are addressed by different parts of the program, or even by different programs altogether, the software package is much easier to develop and to adapt to particular needs.

For example, Unix management of the graphic display is split between the X server, which knows the hardware and offers a unified interface to user programs, and the window manager, which implements a particular policy without knowing anything about the hardware. People can use the same window manager on different hardware, and different users can run different configurations on the same workstation. Another example is the layered structure of TCP/IP networking: the operating system offers the socket abstraction, which is policy-free, while different servers are in charge of the services. Moreover, a server like ftpd provides the file transfer mechanism, while users can use whatever client they prefer; both command-line and graphic clients exist, and anyone can write a new user interface to transfer files.

Where drivers are concerned, the same role-splitting applies. The floppy driver is policy-free -- its role is only to show the diskette as a continuous byte array. How to use the device is the role of the application: tar writes it sequentially, while mkfs prepares the device to be mounted, and mcopy relies on the existence of a specific data structure on the device.

When writing drivers, a programmer should pay particular attention to this fundamental problem: we need to write kernel code to access the hardware, but we shouldn't force particular policies on the user, since different users have different needs. The driver should only deal with hardware handling, leaving all the issues about how to use the hardware to the applications. A driver, then, is "flexible" if it offers access to the hardware capabilities without adding constraints. Sometimes, however, some policy decisions must be made.

You can also look at your driver from a different perspective: it is a software layer that lies between the applications and the actual device. This privileged role of the driver allows the driver programmer to choose exactly how the device should appear: different drivers can offer different capabilities, even for the same device. The actual driver design should be a balance between many different considerations. For instance, a single device may be used concurrently by different programs, and the driver programmer has complete freedom to determine how to handle concurrency. You could implement memory mapping on the device independently of its hardware capabilities, or you could provide a user library to help application programmers implement new policies on top of the available primitives, and so forth. One major consideration is the tradeoff between the desire to present the user with as many options as possible, balanced against the time you have to do the writing and the need to keep things simple so that errors don't creep in.

If a driver is designed for both synchronous and asynchronous operations, if it allows itself to be opened multiple times, and if it is able to exploit all the hardware capabilities without adding a software layer "to simplify things" -- like converting binary data to text or other policy-related operations -- then it will turn out to be easier to write and to maintain. Being "policy-free" is actually a common target for software designers.

Most device drivers, indeed, are released together with user programs to help with configuration and access to the target device. Those programs can range from simple configuring utilities to complete graphical applications. Usually a client library is provided as well.

The scope of this book is the kernel, so we'll try not to deal with policy issues, nor with application programs or support libraries. Sometimes I'll talk about different policies and how to support them, but I won't go into much detail about programs using the device or the policies they enforce. You should understand, however, that user programs are an integral part of a software package and that even policy-free packages are distributed with configuration files that apply a default behavior to the underlying mechanisms.

Splitting the Kernel

In a Unix system, several concurrent processes attend to different tasks. Each process asks for system resources, be it computing power, memory, network connectivity, or some other resource. The kernel is the big chunk of executable code in charge of handling all such requests. Though the distinction between the different kernel tasks isn't always clearly marked, the kernel's role can be split, as shown in Figure 1-1, into the following parts:

Process management
The kernel is in charge of creating and destroying processes, and handling their connection to the outside world (input and output). Communication among different processes (through signals, pipes, or interprocess communication primitives) is basic to the overall system functionality, and is also handled by the kernel. In addition, the scheduler, probably the most critical routine in the whole operating system, is part of process management. More generally, the kernel's process management activity implements the abstraction of several processes on top of a single CPU.

Memory management
The computer's memory is a major resource, and the policy used to deal with it is a critical one for system performance. The kernel builds up a virtual addressing space for any and all processes on top of the limited available resources. The different parts of the kernel interact with the memory-management subsystem through a set of function calls, ranging from simple malloc/free equivalents to much more exotic functionalities.

Filesystems
Unix is heavily based on the filesystem concept; almost everything in Unix can be treated as a file. The kernel builds a structured filesystem on top of unstructured hardware, and the resulting file abstraction is heavily used throughout the whole system. In addition, Linux supports multiple filesystem types, i.e., different ways of organizing data on the physical medium.

Device control
Almost every system operation eventually maps to a physical device. With the exception of the processor, memory, and a very few other entities, any and a I device control operations are performed by code that is specific to the device being addressed. That code is called a device driver. The kernel must have embedded in it a device driver for every peripheral present on your system, from the hard drive to the keyboard and the tape streamer. This aspect of the kernel's functions is our primary interest in this book.

Networking
Networking must be managed by the operating system because most network operations are not specific to a process: incoming packets are asynchronous events. The packets must be collected, identified, and dispatched before a process takes care of them. The system is in charge of delivering data packets across program and network interfaces, and it must correctly put to sleep and wake programs waiting for data from the network. Additionally, all the routing and address resolution issues are implemented within the kernel.

Towards the end of this book, in Chapter 16, Physical Layout of the Kernel Source, you'll find a roadmap to the Linux kernel, but these few words should suffice for now.

One of the good features of Linux is the ability to expand the kernel code at run time. This means that you can add functionality to the kernel while the system is up and running.

Each piece of code that can be added to the kernel is called a module. The Linux kernel offers support for quite a few different types (or "classes") of modules, including, but not limited to, device drivers. Each module is made up of object code (not linked to be a complete executable) that can be dynamically linked to the running kernel by the insmod program and can be unlinked by the rmmod program.

In Figure 1-1, you can identify different classes of modules in charge of specific tasks -- a module is said to belong to a specific class according to the functionality it offers. ...

Read More Show Less

Table of Contents

Preface;
Alessandro’s Introduction;
Jon’s Introduction;
Audience of This Book;
Organization of the Material;
Background Information;
Sources of Further Information;
Online Version and License;
Conventions Used in This Book;
We’d Like to Hear from You;
Acknowledgments;
Chapter 1: An Introduction to Device Drivers;
1.1 The Role of the Device Driver;
1.2 Splitting the Kernel;
1.3 Classes of Devices and Modules;
1.4 Security Issues;
1.5 Version Numbering;
1.6 License Terms;
1.7 Joining the Kernel Development Community;
1.8 Overview of the Book;
Chapter 2: Building and Running Modules;
2.1 Kernel Modules Versus Applications;
2.2 Compiling and Loading;
2.3 The Kernel Symbol Table;
2.4 Initialization and Shutdown;
2.5 Using Resources;
2.6 Automatic and Manual Configuration;
2.7 Doing It in User Space;
2.8 Backward Compatibility;
2.9 Quick Reference;
Chapter 3: Char Drivers;
3.1 The Design of scull;
3.2 Major and Minor Numbers;
3.3 File Operations;
3.4 The file Structure;
3.5 open and release;
3.6 scull’s Memory Usage;
3.7 A Brief Introduction to Race Conditions;
3.8 read and write;
3.9 Playing with the New Devices;
3.10 The Device Filesystem;
3.11 Backward Compatibility;
3.12 Quick Reference;
Chapter 4: Debugging Techniques;
4.1 Debugging by Printing;
4.2 Debugging by Querying;
4.3 Debugging by Watching;
4.4 Debugging System Faults;
4.5 Debuggers and Related Tools;
Chapter 5: Enhanced Char Driver Operations;
5.1 ioctl;
5.2 Blocking I/O;
5.3 poll and select;
5.4 Asynchronous Notification;
5.5 Seeking a Device;
5.6 Access Control on a Device File;
5.7 Backward Compatibility;
5.8 Quick Reference;
Chapter 6: Flow of Time;
6.1 Time Intervals in the Kernel;
6.2 Knowing the Current Time;
6.3 Delaying Execution;
6.4 Task Queues;
6.5 Kernel Timers;
6.6 Backward Compatibility;
6.7 Quick Reference;
Chapter 7: Getting Hold of Memory;
7.1 The Real Story of kmalloc;
7.2 Lookaside Caches;
7.3 get_free_page and Friends;
7.4 vmalloc and Friends;
7.5 Boot-Time Allocation;
7.6 Backward Compatibility;
7.7 Quick Reference;
Chapter 8: Hardware Management;
8.1 I/O Ports and I/O Memory;
8.2 Using I/O Ports;
8.3 Using Digital I/O Ports;
8.4 Using I/O Memory;
8.5 Backward Compatibility;
8.6 Quick Reference;
Chapter 9: Interrupt Handling;
9.1 Overall Control of Interrupts;
9.2 Preparing the Parallel Port;
9.3 Installing an Interrupt Handler;
9.4 Implementing a Handler;
9.5 Tasklets and Bottom-Half Processing;
9.6 Interrupt Sharing;
9.7 Interrupt-Driven I/O;
9.8 Race Conditions;
9.9 Backward Compatibility;
9.10 Quick Reference;
Chapter 10: Judicious Use of Data Types;
10.1 Use of Standard C Types;
10.2 Assigning an Explicit Size to Data Items;
10.3 Interface-Specific Types;
10.4 Other Portability Issues;
10.5 Linked Lists;
10.6 Quick Reference;
Chapter 11: kmod and Advanced Modularization;
11.1 Loading Modules on Demand;
11.2 Intermodule Communication;
11.3 Version Control in Modules;
11.4 Backward Compatibility;
11.5 Quick Reference;
Chapter 12: Loading Block Drivers;
12.1 Registering the Driver;
12.2 The Header File blk.h;
12.3 Handling Requests: A Simple Introduction;
12.4 Handling Requests: The Detailed View;
12.5 How Mounting and Unmounting Works;
12.6 The ioctl Method;
12.7 Removable Devices;
12.8 Partitionable Devices;
12.9 Interrupt-Driven Block Drivers;
12.10 Backward Compatibility;
12.11 Quick Reference;
Chapter 13: mmap and DMA;
13.1 Memory Management in Linux;
13.2 The mmap Device Operation;
13.3 The kiobuf Interface;
13.4 Direct Memory Access and Bus Mastering;
13.5 Backward Compatibility;
13.6 Quick Reference;
Chapter 14: Network Drivers;
14.1 How snull Is Designed;
14.2 Connecting to the Kernel;
14.3 The net_device Structure in Detail;
14.4 Opening and Closing;
14.5 Packet Transmission;
14.6 Packet Reception;
14.7 The Interrupt Handler;
14.8 Changes in Link State;
14.9 The Socket Buffers;
14.10 MAC Address Resolution;
14.11 Custom ioctl Commands;
14.12 Statistical Information;
14.13 Multicasting;
14.14 Backward Compatibility;
14.15 Quick Reference;
Chapter 15: Overview of Peripheral Buses;
15.1 The PCI Interface;
15.2 A Look Back: ISA;
15.3 PC/104 and PC/104+;
15.4 Other PC Buses;
15.5 SBus;
15.6 NuBus;
15.7 External Buses;
15.8 Backward Compatibility;
15.9 Quick Reference;
Chapter 16: Physical Layout of the Kernel Source;
16.1 Booting the Kernel;
16.2 Before Booting;
16.3 The init Process;
16.4 The kernel Directory;
16.5 The fs Directory;
16.6 The mm Directory;
16.7 The net directory;
16.8 ipc and lib;
16.9 include and arch;
16.10 Drivers;
Bibliography;
Colophon;

Read More Show Less

Customer Reviews

Average Rating 5
( 1 )
Rating Distribution

5 Star

(1)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 3 Customer Reviews
  • Anonymous

    Posted March 10, 2005

    specialised skills

    [A review of the 3RD EDITION, 2005.] Device drivers will always be a small speciality in any operating system. Linux is no exception. While it grows strongly, most programmers using it simply can ignore issues of hooking up to various hardware items. Someone has already worked those out. Well, here you are that someone and this book addresses many of your needs. The coding is in C. No fancy object oriented stuff for you. Many higher level OO programmers are simply unaware of the extra overhead it takes. But you need to maximise performance, so it is C for you. Plus, to understand much of the book, it really helps to have written some assembly code, because it makes it easier to understand many low level operations discussed. Prior acquaintance with the overall design of a linux memory manager and interrupt handlers is also good. The book explains well individual issues as they arise. But having a clear, top-down understanding of the linux kernel may give you more context to understand the chapters.

    1 out of 1 people found this review helpful.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted March 10, 2011

    No text was provided for this review.

  • Anonymous

    Posted November 20, 2009

    No text was provided for this review.

Sort by: Showing all of 3 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)