ContentsXXMinimizeifdefs in theSource402402Structure InitializersFixingUpCodeExPostFacto403403ChainofCommandSubmitting BugReports5403Patches404GeneratingPatches404405GeneratingPatcheswithGitSubmittingPatches6406Conclusion406407Bibliography411Indexwww.it-ebooks.infc
ptg xx Contents Minimize ifdefs in the Source 402 Structure Initializers 402 Fixing Up Code Ex Post Facto 403 Chain of Command 403 Submitting Bug Reports 403 Patches 404 Generating Patches 404 Generating Patches with Git 405 Submitting Patches 406 Conclusion 406 Bibliography 407 Index 411 www.it-ebooks.info
ForewordAs theLinuxkernel and the applications that use it become more widely used,we areseeing an increasing number of system software developers who wish to become involvedin the development and maintenance of Linux. Some of these engineers are motivatedpurely by personal interest, some work for Linux companies, some work for hardwaremanufacturers, and some are involved with in-house development projects.But all face a common problem:The learning curve for the kernel is getting longerand steeper. The system is becoming increasingly complex, and it is very large. And as theyears pass, the current members of the kernel development team gain deeper and broaderknowledge of the kernel's internals, which widens the gap between them and newcomers.I believe that this declining accessibility of the Linux source base is already a problemfor the quality of the kernel, and it will become more serious over time.Those who carefor Linux clearly have an interest in increasing the number of developers who can con-tributeto thekernel.One approach to this problem is tokeep the code clean:sensible interfaces,consistentlayout, "do one thing, do it well,"and so on.This is Linus Torvalds'solution.The approach that I counsel is to liberally apply commentaryto the code:words thatthe reader can use to understand what the coder intended to achieve at the time. (Theprocess of identifying divergences between the intent and the implementation is knownas 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 majorsubsystem is intended to do, and of how its developers set about doing it.This, the start-ing point of understanding, is what the written word serves best.Robert Love's contribution provides a means by which experienced developers cangain 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 manypeople: the curious, the application developers, those who wish to evaluate the kernel'sdesign,and others.But the book is also a stepping stone to take aspiring kernel developers to the nextstage, which is making alterations to the kernel to achieve some defined objective.Iwould encourage aspiring developers to get their hands dirty:The best way to under-stand a part of the kernel is to make changes to it. Making a change forces the developerto a level of understanding which merely reading the code does not provide. The seriouskernel developer will join the development mailing lists and will interact with otherdevelopers.This interaction is the primary means by which kernel contributors learnwww.it-ebooks.info
ptg Foreword 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 internals, 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 www.it-ebooks.info
and stay abreast.Robert covers the mechanics and culture of this important part ofkernel lifewellPlease enjoy and learn from Robert's book.And should you decide to take the nextstep and become a member of thekernel development community,consider yourselfwelcomed in advance. We value and measure people by the usefulness of their contribu-tions, and when you contribute to Linux,you do so in theknowledge that your work isof small but immediate benefit to tens or even hundreds of millions of human beings.This is a most enjoyable privilege and responsibilityAndrewMortonwww.it-ebooks.info
ptg 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 www.it-ebooks.info
PrefaceVhenI was first approached about converting my experiences with the Linuxkernelinto a book,I proceeded with trepidation.What would place my book at the top of itssubject? 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 accu-mulated interesting anecdotes and insider tips. With my experiences,I could write a book onhow to hack thekernel and-just as importanthow not to hack thekernel. First and foremost, this is a book about the design and implementation of the Linuxkernel This book'sapproach differs from would-be competitors,however, in that the information is given witha slant to learning enough to actually get work doneand getting it done right. I am apragmatic engineer and this is a practical book.It shouldbefun,easy to read, and usefulI hope that readers can walk away from this work with a better understanding of therules (written and unwritten) of the Linux kernel. I intend that you,fresh from readingthis book and thekernel source code, can jump in and start writing useful, correct, cleankernel 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 inthekernel since the second edition. More important, however, is the decision made by theLinux kernel community to not proceed with a 2.7 development kernel in the near to mid-term. 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 isquite a bit of staying power in a contemporary book on the 2.6 Linux kernel. As the Linuxkernel matures, there is a greater chance of a snapshot of the kernel remaining representativelong 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.UsingThisBookDeveloping code in the kernel does not require genius, magic, or a bushy Unix-hackerbeard. The kernel, although having some interesting rules of its own, is not much differ-ent from any other large software endeavor. You need to master many detailsas withany big project-but the differences are quantitative,not qualitative.1This decision was made in the summer of 2004 at the annual Linux Kernel Developers Summit inOttawa,Canada.Yourauthorwasaninvitedattendee.www.it-ebooks.info
ptg Preface 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. www.it-ebooks.info
It is imperative that you utilize the source.The open availability of the source codefor the Linux system is a rare gift that you must not take for granted. It is not sufficientonly to read the source, however.You need to dig in and change some code.Find a bugand fix it. Improve the drivers for your hardware.Add some new functionality, even if itis trivial. Find an itch and scratch it! Only when you write code will it all come together.KernelVersionThis book is based on the 2.6 Linux kernel series. It does not cover older kernels, exceptfor historical relevance. We discuss, for example, how certain subsystems are implementedin the 2.4 Linux kernel series, as their simpler implementations are helpful teaching aids.Specifically, this book is up to date as of Linux kernel version 2.6.34. Although the ker-nel is a moving target and no effort can hope to capture such a dynamic beast in a time-less manner,my intention is that this book is relevantfor developers and users of botholderand newerkernels.Although this book discusses the 2.6.34 kernel,I have made an effort to ensure thematerial is factually correct with respect to the 2.6.32kernel as well.That latter versionis sanctioned as the"enterprise"kernel by the various Linux distributions, ensuring wewill continue to see it in production systems and under active development for manyyears. (2.6.9, 2.6.18, and 2.6.27 were similar "long-term" releases.)AudienceThis book targets Linux developers and users who are interested in understanding theLinux kernel. It is not a line-by-line commentary of the kernel source. Nor is it a guideto developing drivers or a reference on the kernel API. Instead, the goal of this book isto provide enough information on the design and implementation of the Linuxkernelthat a sufficiently accomplished programmer can begin developing code in the kernel.Kernel development can be fun and rewarding,and I want to introduce the reader tothat world as readily as possible. This book, however, in discussing both theory and appli-cation,should appeal to readers of both academic and practical persuasions.I have alwaysbeen of the mind that one needs to understand the theory to understand the application,but I try to balance the two in this work.I hope that whatever your motivations forunderstanding the Linux kernel, this book explains the design and implementation suffi-ciently for your needs.Thus, this book covers both the usage of core kernel systems and their design andimplementation.I think this is important and deserves a moment's discussion.A goodexample is Chapter 8,"Bottom Halves and Deferring Work,"which covers a componentof device drivers called bottom halves. In that chapter, I discuss both the design andimplementation of the kernel's bottom-half mechanisms (which a core kernel developeror academic might find interesting)and howto actuallyusethe exported interfaces toimplement your own bottomhalf (which a device driver developer or casual hacker canfind pertinent). I believe all groups can find both discussions relevant.The core kernelwww.it-ebooks.info
ptg It is imperative that you utilize the source.The open availability of the source code for the Linux system is a rare gift that you must not take for granted. It is not sufficient only to read the source, however.You need to dig in and change some code. Find a bug and fix it. Improve the drivers for your hardware.Add some new functionality, even if it is trivial. Find an itch and scratch it! Only when you write code will it all come together. Kernel Version This book is based on the 2.6 Linux kernel series. It does not cover older kernels, except for historical relevance.We discuss, for example, how certain subsystems are implemented in the 2.4 Linux kernel series, as their simpler implementations are helpful teaching aids. Specifically, this book is up to date as of Linux kernel version 2.6.34.Although the kernel is a moving target and no effort can hope to capture such a dynamic beast in a timeless manner, my intention is that this book is relevant for developers and users of both older and newer kernels. Although this book discusses the 2.6.34 kernel, I have made an effort to ensure the material is factually correct with respect to the 2.6.32 kernel as well.That latter version is sanctioned as the “enterprise” kernel by the various Linux distributions, ensuring we will continue to see it in production systems and under active development for many years. (2.6.9, 2.6.18, and 2.6.27 were similar “long-term” releases.) Audience This book targets Linux developers and users who are interested in understanding the Linux kernel. It is not a line-by-line commentary of the kernel source. Nor is it a guide to developing drivers or a reference on the kernel API. Instead, the goal of this book is to provide enough information on the design and implementation of the Linux kernel that a sufficiently accomplished programmer can begin developing code in the kernel. Kernel development can be fun and rewarding, and I want to introduce the reader to that world as readily as possible.This book, however, in discussing both theory and application, should appeal to readers of both academic and practical persuasions. I have always been of the mind that one needs to understand the theory to understand the application, but I try to balance the two in this work. I hope that whatever your motivations for understanding the Linux kernel, this book explains the design and implementation sufficiently for your needs. Thus, this book covers both the usage of core kernel systems and their design and implementation. I think this is important and deserves a moment’s discussion.A good example is Chapter 8,“Bottom Halves and Deferring Work,” which covers a component of device drivers called bottom halves. In that chapter, I discuss both the design and implementation of the kernel’s bottom-half mechanisms (which a core kernel developer or academic might find interesting) and how to actually use the exported interfaces to implement your own bottom half (which a device driver developer or casual hacker can find pertinent). I believe all groups can find both discussions relevant.The core kernel www.it-ebooks.info