（已有18条评价）
基本信息
- 原书名：Linux Kernel Development (3rd Edition)
- 原出版社： Addison-Wesley Professional
编辑推荐
能够带领读者快速走进linux内核世界，真正开发内核代码
如果你是一名linux内核爱好者，本书的内容可以帮助你大显身手
如果你是一名普通程序员，本书的内容将会拓宽你的编程思路
如果你初次接触linux内核，本书则可以帮助你对内核各个核心子系统有一个整体把握
内容简介
书籍
计算机书籍
本书基于Linux 2．6介绍了Linux内核的设计与实现，涵盖了从核心内核系统的应用到内核设计与实现等各方面内容，主要内容包括：进程管理、调度、时间管理和定时器、系统调用接口、内存寻址、内存管理、页缓存、VFS、内核同步、可移植性、调试技术等。此外，本书还讨论了Linux 2．6颇具特色的内容，包括CFS调度程序、抢占式内核、块I／O层以及I／O调度程序。
本书详细描述了Linux内核的主要子系统和特点，包括其设计、实现和接口，既介绍理论也讨论具体应用，填补了Linux内核理论和实践细节之间的鸿沟。能够带领读者快速走进Linux内核世界，真正开发内核代码。
如果你是一名Linux内核爱好者，本书的内容可以帮助你大显身手。如果你是一名普通程序员，本书的内容将会拓宽你的编程思路。如果你初次接触Linux内核，本书则可以帮助你对内核各个核心子系统有一个整体把握。
本版新增内容
·增加一章专门描述内核数据结构
·详细描述中断处理程序
·扩充虚拟内存和内存分配的内容
·调试Linux内核的技巧
·内核同步和锁机制的深度描述
·提交内核补丁以及参与Linux内核社区的建设性建议
计算机书籍
本书基于Linux 2．6介绍了Linux内核的设计与实现，涵盖了从核心内核系统的应用到内核设计与实现等各方面内容，主要内容包括：进程管理、调度、时间管理和定时器、系统调用接口、内存寻址、内存管理、页缓存、VFS、内核同步、可移植性、调试技术等。此外，本书还讨论了Linux 2．6颇具特色的内容，包括CFS调度程序、抢占式内核、块I／O层以及I／O调度程序。
本书详细描述了Linux内核的主要子系统和特点，包括其设计、实现和接口，既介绍理论也讨论具体应用，填补了Linux内核理论和实践细节之间的鸿沟。能够带领读者快速走进Linux内核世界，真正开发内核代码。
如果你是一名Linux内核爱好者，本书的内容可以帮助你大显身手。如果你是一名普通程序员，本书的内容将会拓宽你的编程思路。如果你初次接触Linux内核，本书则可以帮助你对内核各个核心子系统有一个整体把握。
本版新增内容
·增加一章专门描述内核数据结构
·详细描述中断处理程序
·扩充虚拟内存和内存分配的内容
·调试Linux内核的技巧
·内核同步和锁机制的深度描述
·提交内核补丁以及参与Linux内核社区的建设性建议
作译者
Robert Love 开源社区的名人，很早就开始使用Linux。目前他是Google公司高级软件工程师，是开发Android移动平台内核的团队成员。他曾受聘于Novell公司，作为Linux Desktop主架构师。他还曾受聘于MontaVista软件公司(后改名为Ximian公司)，作为内核工程师。他的内核项目包括抢占式内核、进程调度程序、内核事件层、inotify、VM增强以及设备驱动程序。他是《Linux Journal》杂志的特邀编辑。
目录
Table of Contents
1 Introduction to the Linux Kernel 1
History of Unix 1
Along Came Linus: Introduction to Linux 3
Overview of Operating Systems and Kernels 4
Linux Versus Classic Unix Kernels 6
Linux Kernel Versions 8
The Linux Kernel Development Community 10
Before We Begin 10
2 Getting Started with the Kernel 11
Obtaining the Kernel Source 11
Using Git 11
Installing the Kernel Source 12
Using Patches 12
The Kernel Source Tree 12
Building the Kernel 13
Configuring the Kernel 14
Minimizing Build Noise 15
Spawning Multiple Build Jobs 16
Installing the New Kernel 16
1 Introduction to the Linux Kernel 1
History of Unix 1
Along Came Linus: Introduction to Linux 3
Overview of Operating Systems and Kernels 4
Linux Versus Classic Unix Kernels 6
Linux Kernel Versions 8
The Linux Kernel Development Community 10
Before We Begin 10
2 Getting Started with the Kernel 11
Obtaining the Kernel Source 11
Using Git 11
Installing the Kernel Source 12
Using Patches 12
The Kernel Source Tree 12
Building the Kernel 13
Configuring the Kernel 14
Minimizing Build Noise 15
Spawning Multiple Build Jobs 16
Installing the New Kernel 16
前言
When I was first approached about converting my experiences with the Linux kernel into a book, I proceeded with trepidation.What would place my book at the top of its subject? I was not interested unless I could do something special, a best-in-class work.
I realized that I could offer a unique approach to the topic.My job is hacking the kernel.
My hobby is hacking the kernel.My love is hacking the kernel. Over the years, I have accumulated
interesting anecdotes and insider tips.With my experiences, I could write a book on how to hack the kernel and—just as important—how not to hack the kernel. First and foremost, this is a book about the design and implementation of the Linux kernel.This book’s approach differs from would-be competitors, however, in that the information is given with a slant to learning enough to actually get work done—and getting it done right. I am a pragmatic engineer and this is a practical book. It should be fun, easy to read, and useful.
I hope that readers can walk away from this work with a better understanding of the rules (written and unwritten) of the Linux kernel. I intend that you, fresh from reading this book and the kernel source code, can jump in and start writing useful, correct, clean kernel code. Of course, you can read this book just for fun, too.
That was the first edition.Time has passed, and now we return once more to the fray. This third edition offers quite a bit over the first and second: intense polish and revision, updates, and many fresh sections and all new chapters.This edition incorporates changes in the kernel since the second edition. More important, however, is the decision made by the Linux kernel community to not proceed with a 2.7 development kernel in the near to midterm.
1 Instead, kernel developers plan to continue developing and stabilizing the 2.6 series. This decision has many implications, but the item of relevance to this book is that there is quite a bit of staying power in a contemporary book on the 2.6 Linux kernel.As the Linux kernel matures, there is a greater chance of a snapshot of the kernel remaining representative long into the future.This book functions as the canonical documentation for the kernel, documenting it with both an understanding of its history and an eye to the future.
Using This Book
Developing code in the kernel does not require genius, magic, or a bushy Unix-hacker beard.The kernel, although having some interesting rules of its own, is not much different from any other large software endeavor.You need to master many details—as with any big project—but the differences are quantitative, not qualitative.
1 This decision was made in the summer of 2004 at the annual Linux Kernel Developers Summit in
Ottawa, Canada. Your author was an invited attendee.
When I was first approached about converting my experiences with the Linux kernel into a book, I proceeded with trepidation.What would place my book at the top of its subject? I was not nterested unless I could do something special, a best-in-class work.
I realized that I could offer a unique approach to the topic.My job is hacking the kernel.
My hobby is hacking the kernel.My love is hacking the kernel. Over the years, I have accumulated
interesting anecdotes and insider tips.With my experiences, I could write a book on how to hack the kernel and—just as important—how not to hack the kernel. First and foremost, this is a book about the design and implementation of the Linux kernel.This book’s approach differs from would-be competitors, however, in that the information is given with a slant to learning enough to actually get work done—and getting it done right. I am a pragmatic engineer and this is a practical book. It should be fun, easy to read, and useful.
I hope that readers can walk away from this work with a better understanding of the rules (written and unwritten) of the Linux kernel. I intend that you, fresh from reading this book and the kernel source code, can jump in and start writing useful, correct, clean kernel code. Of course, you can read this book just for fun, too.
That was the first edition.Time has passed, and now we return once more to the fray. This third edition offers quite a bit over the first and second: intense polish and revision, updates, and many fresh sections and all new chapters.This edition incorporates changes in the kernel since the second edition. More important, however, is the decision made by the Linux kernel community to not proceed with a 2.7 development kernel in the near to midterm.
1 Instead, kernel developers plan to continue developing and stabilizing the 2.6 series. This decision has many implications, but the item of relevance to this book is that there is quite a bit of staying power in a contemporary book on the 2.6 Linux kernel.As the Linux kernel matures, there is a greater chance of a snapshot of the kernel remaining representative long into the future.This book functions as the canonical documentation for the kernel, documenting it with both an understanding of its history and an eye to the future.
Using This Book
Developing code in the kernel does not require genius, magic, or a bushy Unix-hacker beard.The kernel, although having some interesting rules of its own, is not much different from any other large software endeavor.You need to master many details—as with any big project—but the differences are quantitative, not qualitative.
I realized that I could offer a unique approach to the topic.My job is hacking the kernel.
My hobby is hacking the kernel.My love is hacking the kernel. Over the years, I have accumulated
interesting anecdotes and insider tips.With my experiences, I could write a book on how to hack the kernel and—just as important—how not to hack the kernel. First and foremost, this is a book about the design and implementation of the Linux kernel.This book’s approach differs from would-be competitors, however, in that the information is given with a slant to learning enough to actually get work done—and getting it done right. I am a pragmatic engineer and this is a practical book. It should be fun, easy to read, and useful.
I hope that readers can walk away from this work with a better understanding of the rules (written and unwritten) of the Linux kernel. I intend that you, fresh from reading this book and the kernel source code, can jump in and start writing useful, correct, clean kernel code. Of course, you can read this book just for fun, too.
That was the first edition.Time has passed, and now we return once more to the fray. This third edition offers quite a bit over the first and second: intense polish and revision, updates, and many fresh sections and all new chapters.This edition incorporates changes in the kernel since the second edition. More important, however, is the decision made by the Linux kernel community to not proceed with a 2.7 development kernel in the near to midterm.
1 Instead, kernel developers plan to continue developing and stabilizing the 2.6 series. This decision has many implications, but the item of relevance to this book is that there is quite a bit of staying power in a contemporary book on the 2.6 Linux kernel.As the Linux kernel matures, there is a greater chance of a snapshot of the kernel remaining representative long into the future.This book functions as the canonical documentation for the kernel, documenting it with both an understanding of its history and an eye to the future.
Using This Book
Developing code in the kernel does not require genius, magic, or a bushy Unix-hacker beard.The kernel, although having some interesting rules of its own, is not much different from any other large software endeavor.You need to master many details—as with any big project—but the differences are quantitative, not qualitative.
1 This decision was made in the summer of 2004 at the annual Linux Kernel Developers Summit in
Ottawa, Canada. Your author was an invited attendee.
When I was first approached about converting my experiences with the Linux kernel into a book, I proceeded with trepidation.What would place my book at the top of its subject? I was not nterested unless I could do something special, a best-in-class work.
I realized that I could offer a unique approach to the topic.My job is hacking the kernel.
My hobby is hacking the kernel.My love is hacking the kernel. Over the years, I have accumulated
interesting anecdotes and insider tips.With my experiences, I could write a book on how to hack the kernel and—just as important—how not to hack the kernel. First and foremost, this is a book about the design and implementation of the Linux kernel.This book’s approach differs from would-be competitors, however, in that the information is given with a slant to learning enough to actually get work done—and getting it done right. I am a pragmatic engineer and this is a practical book. It should be fun, easy to read, and useful.
I hope that readers can walk away from this work with a better understanding of the rules (written and unwritten) of the Linux kernel. I intend that you, fresh from reading this book and the kernel source code, can jump in and start writing useful, correct, clean kernel code. Of course, you can read this book just for fun, too.
That was the first edition.Time has passed, and now we return once more to the fray. This third edition offers quite a bit over the first and second: intense polish and revision, updates, and many fresh sections and all new chapters.This edition incorporates changes in the kernel since the second edition. More important, however, is the decision made by the Linux kernel community to not proceed with a 2.7 development kernel in the near to midterm.
1 Instead, kernel developers plan to continue developing and stabilizing the 2.6 series. This decision has many implications, but the item of relevance to this book is that there is quite a bit of staying power in a contemporary book on the 2.6 Linux kernel.As the Linux kernel matures, there is a greater chance of a snapshot of the kernel remaining representative long into the future.This book functions as the canonical documentation for the kernel, documenting it with both an understanding of its history and an eye to the future.
Using This Book
Developing code in the kernel does not require genius, magic, or a bushy Unix-hacker beard.The kernel, although having some interesting rules of its own, is not much different from any other large software endeavor.You need to master many details—as with any big project—but the differences are quantitative, not qualitative.
序言
As the Linux kernel and the applications that use it become more widely used,we are seeing an increasing number of system software developers who wish to become involved in the development and maintenance of Linux. Some of these engineers are motivated purely by personal interest, some work for Linux companies, some work for hardware manufacturers, and some are involved with in-house development projects.
But all face a common problem:The learning curve for the kernel is getting longer and steeper.The system is becoming increasingly complex, and it is very large. And as the years pass, the current members of the kernel development team gain deeper and broader knowledge of the kernel’s nternals, which widens the gap between them and newcomers.
I believe that this declining accessibility of the Linux source base is already a problem for the quality of the kernel, and it will become more serious over time.Those who care for Linux clearly have an interest in increasing the number of developers who can contribute to the kernel.
One approach to this problem is to keep the code clean: sensible interfaces, consistent layout,“do one thing, do it well,” and so on.This is Linus Torvalds’ solution.
The approach that I counsel is to liberally apply commentary to the code: words that the reader can use to understand what the coder intended to achieve at the time. (The process of identifying divergences between the intent and the implementation is known as debugging. It is hard to do this if the intent is not known.)
But even code commentary does not provide the broad-sweep view of what a major subsystem is intended to do, and of how its developers set about doing it.This, the starting point of understanding, is what the written word serves best.
Robert Love’s contribution provides a means by which experienced developers can gain that essential view of what services the kernel subsystems are supposed to provide, and of how they set about providing them.This will be sufficient knowledge for many people: the curious, the application developers, those who wish to evaluate the kernel’s design, and others.
But the book is also a stepping stone to take aspiring kernel developers to the next stage, which is making alterations to the kernel to achieve some defined objective. I would encourage aspiring developers to get their hands dirty:The best way to understand a part of the kernel is to make changes to it. Making a change forces the developer to a level of understanding which merely reading the code does not provide.The serious kernel developer will join the development mailing lists and will interact with other developers.This interaction is the primary means by which kernel contributors learn and stay abreast. Robert covers the mechanics and culture of this important part of kernel life well.
Please enjoy and learn from Robert’s book. And should you decide to take the next step and become a member of the kernel development community, consider yourself welcomed in advance.We value and measure people by the usefulness of their contributions, and when you contribute to Linux, you do so in the knowledge that your work is of small but immediate benefit to tens or even hundreds of millions of human beings. This is a most enjoyable privilege and responsibility.
Andrew Morton
But all face a common problem:The learning curve for the kernel is getting longer and steeper.The system is becoming increasingly complex, and it is very large. And as the years pass, the current members of the kernel development team gain deeper and broader knowledge of the kernel’s nternals, which widens the gap between them and newcomers.
I believe that this declining accessibility of the Linux source base is already a problem for the quality of the kernel, and it will become more serious over time.Those who care for Linux clearly have an interest in increasing the number of developers who can contribute to the kernel.
One approach to this problem is to keep the code clean: sensible interfaces, consistent layout,“do one thing, do it well,” and so on.This is Linus Torvalds’ solution.
The approach that I counsel is to liberally apply commentary to the code: words that the reader can use to understand what the coder intended to achieve at the time. (The process of identifying divergences between the intent and the implementation is known as debugging. It is hard to do this if the intent is not known.)
But even code commentary does not provide the broad-sweep view of what a major subsystem is intended to do, and of how its developers set about doing it.This, the starting point of understanding, is what the written word serves best.
Robert Love’s contribution provides a means by which experienced developers can gain that essential view of what services the kernel subsystems are supposed to provide, and of how they set about providing them.This will be sufficient knowledge for many people: the curious, the application developers, those who wish to evaluate the kernel’s design, and others.
But the book is also a stepping stone to take aspiring kernel developers to the next stage, which is making alterations to the kernel to achieve some defined objective. I would encourage aspiring developers to get their hands dirty:The best way to understand a part of the kernel is to make changes to it. Making a change forces the developer to a level of understanding which merely reading the code does not provide.The serious kernel developer will join the development mailing lists and will interact with other developers.This interaction is the primary means by which kernel contributors learn and stay abreast. Robert covers the mechanics and culture of this important part of kernel life well.
Please enjoy and learn from Robert’s book. And should you decide to take the next step and become a member of the kernel development community, consider yourself welcomed in advance.We value and measure people by the usefulness of their contributions, and when you contribute to Linux, you do so in the knowledge that your work is of small but immediate benefit to tens or even hundreds of millions of human beings. This is a most enjoyable privilege and responsibility.
Andrew Morton
