Write and Submit your first Linux Kernel Patch
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Kroah-Hartman, Greg
As A core member of the Linux Kernel team, Greg will show us how to write a kernel patch. This talk will cover the steps necessary to properly compose, describe, and submit a Linux kernel patch. It will cover the basic usage of git, and how that works with the Linux kernel development cycle. Attendees should have a solid grasp of the C language, and know how to build and install, a Linux kernel from scratch
 My name is Greg Crow Hartman. I work at Noval, Susie Labs division. I'm a fellow there. I do kernel development for them. And I've been doing a lot of work on Moblin or Goblin. That's what this is. This is open Susie version of Moblin. So it looks a little kind of funny. That's what it is. It's a lot of fun. The talk is online, that location, including the slides and a big, long article that was written. So all the words are there. So you can read it if you want to read it. So write and submit your first kernel patch. The Linux kernel last year had over 2,000 individual contributors. Now half those people only submitted one patch. Then half the half submitted two. Half the half the half did three. It's a little exponential curve. But those 2,000 people, that 1,000 people that did one patch, that's good. We need more people contributing. After this talk, you guys can contribute. So there's what? 2,000 people here. So we'll double our quantity next year. Awesome. So first thing in the Linux kernel, even if you don't want to program, you don't want to do anything, but you have questions about the source code, anything, the documentation, how to file. It tells you everything. And what it doesn't tell you, it tells you links to other files, other website, other locations of what you're curious about. If there's any question that you have that isn't answered by that or the other links, let me know. Let other people know. My email address is at the front. We maintain this. This is a very, very good resource. You have a question. It's there. We write lots and lots of documentation, and nobody reads it. But hey, I'm trying. So what are we going to not cover in this talk? I'm not going to teach you how to build the Linux kernel. I wrote this book a number of years ago for O'Reilly. The Linux kernel in that shell, it's free. It's online. You don't have to buy it. I really get no money if you do buy it. That tells you how to build the kernel. It tells you how to install it, how to configure it, how to do it all. It's all online, free. That'll teach you how to install a kernel. If you can install your own kernel that you built, you're almost there. That's it. It's a very good thing. So read that book. I'm also not going to teach you C. I actually learned C at the time of my talk. I had Minux in college. I had to learn C and write a floppy driver as my very first assignment. It was hell. But I loved it. I did not do good in that class in university. But I loved it. It's an allegory. Very good book. It's a very small language as far as the specification. Very, very powerful. People can call it a portable assembler. That's true. It runs on anything. I've written C code for microcontrollers that had one and a half registers. It can be done. That was a fun processor. All right. What are we going to cover? Here's what we're going to cover. Talk about Git, the Linux kernel source code control tool. It's a very, very powerful source code control. Our coding style, what the kernel does, how to fix a file once you find what you want to change. So talk about how to find something to change, how to generate the patch, and how to email the patch. That last one gets so many people. Email clients suck. Email servers suck. They like stripping off tabs. You guys see it. You're developers. Convert tabs to spaces. Spaces to tabs. Wrap lines. Don't wrap lines. Exchange server for Microsoft will not send Linux kernel patches through it. It just won't work. So much so. Microsoft has now contributed to Linux kernel. Microsoft has an internal Linux server that they use to send me patches. It works great. Intel has the same thing. IBM has the same thing. Novell has the same thing. No, we don't use Exchange. We use GroupWise, which is actually worse. Oh, this video? Sorry. Different division. GroupWise started on the Amiga. Anyway, so let's talk about Git. Git is awesome, if you guys don't know about it. So Git is a Linux source code control tool. The Linux kernel uses it. Lots of other people use it. It's very, very good. I'm not going to go over how to use it, how to install it, but I'll talk about how you can use it for the kernel. It's a very, very powerful thing. There's really good tutorials online to use it. So read them. There's very good books online. Some of them are open. Some of them aren't. There's some very good stuff. It's out there. But some things about Git that's really good. So first off, you have to know where you're going to get our kernel tree from. And it's at that tiny location. It's easier to Google it. But there. So you clone the tree somewhere. So I've cloned the tree, and I'm in this directory. In my directory, and Git status. Nothing's going on. And this is a little tiny, cheap laptop in Git rocks. It does have a good hard drive, though. So one thing when you start using Git is you don't want to be modifying the main branch. You want to make all your changes somewhere else. Because you're not Linux, so you're not going to be able to modify his tree. He takes patches from other people, and then you pull. So you don't want to mess with the main branch of development. So what we're going to do is we're going to branch. We're going to Git branch. So let's make something called Git branch tutorial. So I've got two branches. The little star says which one I'm on right now. Masters the main one. I really want to switch to the tutorial branch. So Git, check out tutorial. And hey, it does bash completion. Switch to branch tutorial. And now we're on the tutorial branch. So anything I do is on my separate branch. I won't mess with Linux's. I've got a call. It's good. We also want to be on a separate branch because we want to know what changes we have made compared to him. Because we want to send all those changes off to somebody. So we want to know how to differentiate ourselves. So that's a nice thing to do. And then we'll always show you what branch you're on. I'm on the branch tutorial. So Git branch. Make your own branch. Don't be afraid of branches. They're good for you. They work nice. So let's talk about the coding style in the Linux kernel now, now that you guys know everything about Git. First off, you guys do a lot of development with other people. Why do we care about a coding style? And it sort of comes down to one thing, your brain. This is a study done a long time ago. You guys can read the quote. But what it really means is your brain sees patterns. And it's very, very good at pattern-mashing and seeing things that are out of the ordinary of those patterns. So when you use the same coding style over and over and over, the format of stuff goes away. Your brain can't see that. You can see the metadata inside. You see the bugs. You see the logic inside much, much better. So only thing that matters about a coding style is it's consistent. I don't care where you put your braces. Your tabs, your spaces. If you're going to do it for your project, be consistent. If you're on a project that doesn't have a coding style, make one. Well, don't use a good new one. But make another one. Yeah, my brain hurts watching the new one. But that's good. Those guys know their brain feels good, and their brain hurts when they write Linux kernel code. So it works. You can switch between them. But be consistent. Seriously, if you're a one-person project, pick a coding style and stick to it. Because you want somebody else to join, somebody else join. Hopefully you should. I hope there's no major projects these days without a coding style. I hope. It just matters. Because the real goal is, I want you to fix my bugs. And you want me to fix your bugs. We want other people to read the code. Reading code is very, very important. When you first start off in university or learning how to program, you start writing code. But when you first start learning how to speak a language, you don't start writing it right away. Or music. You don't start writing music right away. You read a lot. Reading a lot is very, very good. So having code that can be easily read is very important. The Linux kernel is one of the largest code bases in the world, largest developed project in the world ever has happened. And it's very, very readable. It's very good code. It's very easy to understand. Even at C, it's very easy to understand. So that's why it matters. It really matters. It's all down to your brain. So what do we do? We have it. It's in documentation coding style. You'll notice that's camel case. I don't know why. We don't do camel case. But in there, it's a very readable document. It's gotten longer over the years. People started being nitpicky. You can get too particular about a coding style. The best thing is have a few guidelines and stick to that. When you start getting where you put some other things, it gets too much. You can argue, like everybody likes to argue. So here's our rules. Use tabs. Yes, sorry. Yeah, but it's consistent. Hopefully you don't do that in your projects. And I won't contribute. But you won't contribute to mine. Use tabs like God intended. All tabs are eight characters and 80 character line limit. This last one I hate. And it's actually starting to go away. We realize our terminals are not 20 years old. They're not 80 characters only. So we do start taking things long. But the interesting thing about this combination, if your tabs are eight characters and your code starts going way over here, and you hit the 80 character line limit soon, so your code starts wrapping and looking really bad, what that means is your code is getting too complex. You should be refactoring it, making it smaller and easier to understand. So by sticking to 80 characters is a very good limit on yourself to make easily to read code. Means you're doing something wrong in the logic. It shouldn't look like that. You shouldn't be running into that limit. Now long strings, long function names, or long function declarations you can break, strings you really shouldn't because you want to grip for them easily. But so 80 characters is, even though if we do bump into 132, which we probably will, it's a good logic check. Means you're doing something wrong. All right, so people hate tabs. Braces in the sea, like Kernighan and Richie show, upper right, lower left, all the way over. That's it. There's nothing other to think. Fun thing, error numbers. All our error return values are always negative in the kernel. Zero means true. That's Unix for you. We never return a positive number. Very, very, very rarely return a positive number. So braces, like that. What do we do with it? It's else statement. Again, wrap it. There and there. Report error, go tos. We like go tos. Go tos are really important because in the kernel, we do locking. You lock because we're doing multi-threaded, multi-processor stuff. And when you enter a function, you grab some locks. When you exit a function, you unwrap some locks. Report error, if I was to do something, I want to jump to the place where I unlock everything. If I was going to return here, I would have to unlock, unlock, unlock. And then you forget because somebody changed the locking a little bit. It's more important to jump to the end and do that. Go tos backwards RMS. I wouldn't recommend that. The kernel does in a few places, but it's scary. The scheduler. I write drivers, not schedulers. So like that. That's it. It's a real simple coding style, real easy. Now here's the one that a lot of corporations get upset about. We don't do it for single argument if statements. That's it. Good party. Single argument if statements, no braces. We want to keep the lines so you can see it easier. It's as simple as that. But if one of these arguments, like the if or the else, is multiple lines, then you can put the braces on both sides. It's OK. That's it. And the other place for braces in a function, all the way to the left, do something. Return zero. Again, returning zero means true. Integer is the way we return values. That's it. Small variable names, lowercase, underscores, small, logically easy to understand function names that do something that say what they're going to do. No Hungarian notation, no returning, telling you what type of the variable is. That's what the C compiler is for. It will check it for you. Nothing crazy. So that's it. Feel good? Good. We have a tool that will check it all for you. Check patch.pl in the script directory. It's a fun little tool to run on the kernel itself. But it'll check your patch. If you make some modifications to the kernel, you run this tool on it. It'll tell you if it's good or not. If you've done everything you're supposed to do or not. It's a really, really fun tool. It's written by a Perl guy, so don't hold that against us. Check patch. You can do a file. You can just run it against a file. Terse. Let's pick a file. Drivers, staging, comedy, drivers. See. I have no cash. There we go. So it says, if you see at the very bottom down there, this file has zero errors, 39 warnings, this is 312 lines checked. The record so far, I had a driver from a company that would remain anonymous. That was 300 lines long to driver, a small driver. It had 752 errors. More than twice the number of errors. Then there was, I don't know the number of warnings, per line of code. That was with comment blocks. We took the logic, and we deleted it and rewrote it. Anyway, so here's a nice thing. Warning, braces are not necessary for any arm in that statement. So let's make that our change. So in the drivers staging directory, I maintain that. It's all the bleeding edge stuff. It's the crappy drivers that are not been merged into the kernel pretty properly. Every place in there, there's a to-do file. You can read the to-do file if you're curious about what you want to do. You don't know what you want to check. You don't want to know what you want to do for writing kernel code. There's a big to-do list in there. Do one of those things, send us patches, and we're happy. You do it. So cleaning up the code to make a check patch clean is always on that list. So we'll do that for here. So let's, mdrivers. I can't see. So on this line down here, I'll move it up for the people on the bottom. Maybe not. That's the whole file. Let's edit it. Run it again. And there's one last warning. Nice. So hey, we've made a kernel patch. Seriously. I mean, people do check patch. People fix spelling errors. That's awesome. We need that. People removed all the curse words, which damn it was not fun. I like those in there. I'm a hardware developer. I do embedded. I used to do embedded, now I do drivers. So cursing at the hardware is my day-to-day life. So you like taking it out in the code. Working around hardware bugs, that's what I do. All right. So let's see what it does. Git, instantly, the whole 600 meg kernel tree told me, instantly, what was modified. That's fast. That's awesome. Macquarie also does this. Very nice. Let's look at the diff. It shows I subtracted some line. I subtracted this line. Hey. Oh. Little boingy. Subtracted that line, added this, subtracted that, added that, subtracted that, added that. That's it. That's a diff. This is how we do kernel changes. We make diffs. Diff you send to the patch tool. We call them patches. This is a format. It's a very common format. It's been around forever. Larry Wall made it. Very, very powerful. It enables us to send changes through email to other people. You can read it. You can review it. You can look it up and say, hey, that's obviously right. I removed that, added that. Good stuff. Oh, I guess we should build it. Little thing, if you want to only build a certain sub directory, you can. Let me hold kernel. So let's just build that one. Builds the file. Hey, built. Ship it. Seriously. So I maintain the stable kernel releases. I do all the releases for the stable kernel. And people ask me, well, how do you test it all? I said a built, right? And then all the QA department yells at you. But I'm serious. The Linux kernel does not have a test suite. It's very, very hard to have a test suite for hardware interactions. The way my hardware and my laptop works is different than the way your hardware and your laptop does. So the best thing you can ever do for us is if you just build the kernel and tell us if you have a problem, that is our QA cycle. We rely on the community to do that. And that's the only way we can physically do this. Linux supports more hardware, more different devices than any other operating system ever. It currently does and ever has. It supports more processors than any other operating system. Sorry, not BSD. You guys lost a couple years ago. Many years ago, five. And all those drivers work on all those processors. Linux kernel is amazingly crazy. It's something that nobody has ever done. We scaled, we were the number one phone by Quantity in 2008. And we were 85% of the world's top 500 supercomputers. Same year, same code. That's amazing. But we do it by everybody testing. Everybody tests on things. So if this thing built, it built before, and it builds now, logically I can look at it, and that's all I can do. If it runs on my machine, I don't have this hardware. You don't have this hardware. So it's OK. But if somebody else does have this hardware, they can report the problem. It sounds bad, but dealing with a lot of these things is this is the only way you can do it, is use it. Writing test cases for hardware is hard. I had a fun bug where if I plugged two USB devices in while streaming audio out of the third one, then I could reproduce the bug. You can't automate that. I have this giant box of USB devices that I test with. It's fun. So OK. So we made the patch. So let's commit it. So we're going to commit. We're going to make a change into our Git tree. So Git pops up your favorite editor. Mine's the one true one. No, I don't care. You can do whatever you want. You don't tell me what to do. I don't tell you. OK. So we're going to write a commit message. So the good thing about a commit, well, let's show you an example. Here's a commit. So this is what's in the kernel tree. You can look up this commit. The very first line on the top, want to make a nice short, succinct summary of what this does. In the short log, this will show up. So it's USB OTG, which is on the go. That means USB is in the client itself. So Linux is running out there. Fix the bug on a remove path without transceiver. Looks nice. Nice, short, succinct. Then we have a few sentences. This one just says, hey, the scattered driver's removed. No transceiver find. It was a bug. And then we have a signed off by. Explain signed off by what we do in a little bit. And then that got sent to the subsystem maintainer for USB on the go, which is David Brunel. He said act. Looks good to him. He sent it off to me. I'm the maintainer of USB. I say I signed off by it. And then I got it into Linux's tree. So that's that. There's the patch. It removed. We want to actually test if X is there or not before we access it. Otherwise, it would have been a nice little oops. And that's it. That's what the patch. So succinct line, summary of what it does, who wrote it? But that's signed off by. Let's see what that means. When we say signed off by, we are agreeing to this. We have something called the developer certificate of origin. And it means this. You guys can read that. You made the change. You based it. Or you based it on somebody else's change, which was a compatible license. Or it was provided by me by somebody like that. And I didn't touch it. So somebody sends me a patch. And it's public. This is what in the Linux kernel. So every single line of the Linux kernel is reviewed by at least two people. And they sign off on it, saying legally this is it. It's the best audited body of code in the world. You can say who modified this line. And it'll tell you. So signed off by is a very good thing from the legal standpoint. We also do it as the path of blame. If this patch breaks something, you go, hey, Greg, you broke it. David, you acknowledged this. And Robert, you're the one who really is responsible. So all of us take ownership of it. If my name is on a patch that breaks something, it's up to me to fix it. Contribution is public. We also don't take anonymous contributions to the Linux kernel. If I know you're anonymous, I cannot take it. If I don't know you're anonymous, I can take it. It's just a legal thing. That's all we do. That's all. And companies agree to this. You own your copyright on any files you have. Some countries, like Europe, are not allowed to absolve your copyright. So it's very good. You own your copyright. Your company can own the copyright. Everything is great. That's what signed off by means. So we did something. So I'm going to say, in the staging directory, the column D drivers, the SSV DNP driver I fixed, a brace. This one's kind of obvious. And I'll say, signed off by. I have a little macro that does that. And let's commit it. Boom. You can see, if you do get logged, the very first thing, my patch. Do that. You can see if you do get show. There's the patch, in patch format, who authored it. When it was authored, the commit ID. You can see get show pretty equals fall. Author and who committed it to a tree? Because authorship is who wrote it, but it might not be who committed it to a tree. You send a patch to me to send off to somebody else. I'll end up committing it to get somewhere. But you authored it. Authorship is very important. We preserve authorship everywhere. So we don't have really good ways of two people wrote a patch, but that's usually pretty rare. Authorship's very important. So there. Patch. Cool. So get diff. Show the diff. Commit. Show it. Oh, format patch. Let's make this patch. It is a patch, so remember we had two branches. Tutorial master. So we want to take this patch and send it off to somebody. But we have to make it into a patch. So we have a nice tool, a nice thing, get format. And I want to say I want to do all the patches. If I've done more than one, I could just do it for one. I want to do from master to tutorial. And hey, it made a patch. It made one file. So if I look at this, it turned it into an email. Imagine that. This is good. It says, when I wrote it, date, subject, fix the coding style, signed off by, what was modified, looks pretty, looks nice. Perfect. This is great. Now you have a patch. Now what do you do with it? This is hard. So email clients, GUI-based email clients, will corrupt these. It's not very good. We have a whole file in the kernel and documentation directory called email-clients.txt how to configure your email clients to send patches, how to configure Gmail to send patches, how to work around Thunderbirds issue, work around all these issues. Kmail works really well. Evolution, OK. I use MUT. MUT works great. Send mail? You can pipe it to send mail? You can? Or you can do get send mail. But wait, who do you want to send it to? Right? You've got to know who to send it to. So we've got something fun. We even wrote a script for it. Get maintainer. And you can send it a patch. Oh, wait, wait, wait. We want to do Scripps check patch. It's good. You can send it off now. OK. I've actually done this and it failed. Don't laugh. Get maintainer. So there's a nice script. It goes and looks at the kernel tree. It looks at the maintainer's file. There's a maintainer's file in the directory to who maintains what. And looks at who's actually committed to what file. So if you ever touch a floppy driver, tag you're it. It says to send it to Greg, which is me. Send to bills, modified it. Test this, modified it. And then to mailing lists. Because you want to send to mailing lists, we do all our development in public. So those are the people I want to send this email to. So let's send the email. Oops, I want to say to me. That's not good. I'll copy to osl.org and copy the next kernel. Now you can do something called, oh, what is this? There's an option that you can edit. If you're sending multiple patches, you can say start up patch. The first patch you want to send is a little summary of everything. So you want to say, these patches are going to do this. I'm sending up one file, and you don't really need a summary. This one is so simple, it's self-explanatory. So if you're doing these kind of changes, and I really recommend you do these changes, just send me one patch. But if you're sending more than one patch, or a patch that depends on another patch, then you need to tell me what order in which to apply them in. Patches for Linux kernel need to do one thing only. Don't be a replace this subsystem. We want to see your work. Like your old professor used to say for math, show me your work. Show me the individual logical steps of what you did. They can be in order. So one depends on the other, depends on the other. And that's really good. Linux kernel works on the fact that other people review it. You have a 15 patch, patch set. Patch number five didn't do something quite right. So we'll apply the first four, and then you'll take the review and work on the rest of them. And that's work. It's an iterative design process. I wrote the Linux driver core, along with somebody named Pat Michelle. When we came up with this idea, we wanted to unify the way drivers worked in the two five series. Some other kernel developers saw all the work we were starting to do. They said, no, we can make that and make it even a more base type, sort of a common type in the kernel called k object that all other types of objects can do. And then we realized, hey, that's reference counting. And then we can refactor that and make that a smaller thing. So we have a very, very flexible type system in the kernel. We do multiple inheritance object overloading in C. Virtual functions, as fun. Some days I wish I had a C++ compiler. So but it's showing your work, seeing other people seeing the idea and saying, no, it could be made better. Recently, Google's been in the news for not getting their code into the kernel because they dropped big chunks on the kernel. And they didn't go through the review design review process. We said, hey, but wouldn't be great if you tweaked this and did this this way. And you can't just drop big chunks. You can add a whole new driver? That's fine. You're not touching anything else. Add a new file system? Great. If you want to change the core VFS like RyzerFS4 wanted to do, no, it's not good. You have to go through review process. Changing little things in drivers is very simple. Changing things in the core kernel isn't so simple. But that's good. You don't want us to be able to modify the core kernel that everybody uses as easily as you can do other things. But we should always be able to take spelling fixes for things. So let's send the mail off. So it'll ask me, who do I want it to come from? Hey, it'll come from me. It guesses based on your IDs. Do that. And if you want to do a reply to, it'll do that. I don't want to do that. And then it'll ask me, hey, I'm going to send this to this person, copy these people. It's going to look like this. Because it looks through the email, guess, is this OK? It's nice. I'll say yes. It talks to my servers halfway around the world. And it worked. Result OK. And then we do a little notification get. We'll tell you something. Yeah. How does that send the email number with server icon here? It's equal to 8. My internet is 1. Yes, how does get send mail know what to do? There's a zillion options. I have in my get config, I say my SMT server is my local SMMTP. And then that has its configuration that knows where to go. So if you Google or you look at the man page for send email, it'll do lots of things. It'll tell you how to connect to Gmail. You can use Gmail remote IMAP to do this, to send patches off. You can point it to somewhere else. You can point to your local send mail. It's extremely configurable that way. It's very good for sending spam, too. It was based on a Perl script I wrote a long time ago that actually I have a rule in spam assassin that's named after me. Though I used to send patches out, but other people got a hold of it. So that's it. So send email off. We'll look in a minute. My server doesn't refresh that fast. See if it really got there. So get maintainer. Get maintainer is fun to know who to send the patch to. But it's also good if you think there's a problem in this file. So let's pick a file in the kernel. Pick a file. Give me a file. Keyboard, which one? All right, drivers, head. Head, easy key. OK, yearzy is the head maintainer. Peter worked on the file. Yearzy Slavi also worked on it. And you want to send it to the input list and the external. Boom. So if you have a question about that file, hit them all. The Linux kernel has been known to be a not nice place to play. But people respond well, hopefully in ways that might seem aggressive at times. But if you've ever seen internal email lists on technical people or companies, this is, the Linux kernel is nice. The thing, people will critique your code. They won't yell at you, hopefully. You don't go and say, wouldn't it be great if you do this? You show code. You do things like that. The best way to get somebody to do work for you, this works once a year. Take advantage of it. But don't abuse it. Make some changes to the kernel that you know are wrong. And then submit it. Send it to the maintainer. Send it to the mailing list. The maintainer will go, oh, crap, that's wrong. I can't take that, but I'll do it right. Because I have to do it right because that might go in instead. So you can do that. But here, you can see who wrote that. Each thing. So if you had a problem with that file, mess with the yearsy. I'll do the same thing. Stage R, driver's head. So before I said, remember, we can see who wrote what line of the code and what did it. There you go. You want to see who wrote every single line, who reviewed it. This all came in as one big patch. Oh, here's a change from Peter. And then I can do get show that commit. And boom. I can see that Peter changed something to be a emit function. So there. And two people reviewed that line. I mean, that's an extremely, extremely powerful thing. Get is very good. And look how fast that. I mean, this is a cheap little laptop. It worked really good. I just picked something random. Anyway, it gets awesome. I'll refresh my mail and go to the next thing. So here's a checklist for what you need to do. There's actually a checklist in the documentation directory. But it makes sure it builds. We almost forgot that one. Makes sure it's from the right person. Some companies don't let you contribute to the external. So make sure you contribute from your home email address instead. We track who writes what in the kernel. We do a report every year through the Linux Foundation. If you send a patch in and I can't figure it out by your domain, you'll receive an email from me in a few months. Just asking. You don't have to respond, but we try and keep track of it. We want to know who's doing the work. Other people reported 80% of the work done in the Linux kernel is done by companies, paid contributions. Some people think it's a bad thing. I think it's really good that 20% is done by people who aren't paid. This is their hobby. The problem with that 20% is if you start doing patches, you will get hired, and that'll be your job. This used to be my hobby. Now I have no hobby. Other kernel developers have known to burn out and start other hobbies, and then they turn that into a company, and then they go back to kernel development. It's happened a lot. So make sure a concise subject. Explain the patch and signed off by. That's it. This is a very, very simple thing to do. Come on. Anybody can do this. Literally, anybody. Let's see if I can show it. Aha, there's my patch. It sent to me, came to me. Cool. And there it is. Not going to apply it. So you send off a patch. Somebody said, how do you know what to do if nobody responds back? And that's a good question. Give people a week. Some people travel a lot. If they don't say anything in a week, send it to them again. Be persistent. You're not being annoying. You're being persistent. It's OK. I want to be reminded that me, as a maintainer, I'm not doing my job. Send it off. Keep bugging us. Persistence is the key. It literally is. It really is. Just be persistent. That's all I can say. It works really well. My inbox. Yeah. Checklist. And kernel newbies group. If you're afraid of the next kernel and you're afraid of asking a dumb question, kernelnewbies.org, very, very good resource. Wonderful Wiki explains what is in each kernel release in a nice, concise summary. There's an IRC channel that's awesome. It has about 600 people in it, but nobody talking. The problem is people show up and they're like, ah, it is not for off-topic stuff. You ask a question, it will be answered. I'm in there. A lot of the kernel developers are in there. It's a really good spot, that IRC channel. They have a mailing list. There's only one stupid question you can ask on this mailing list, and that's a question that was already asked this week. Read the archives. Just read the archives for a week. If you can't find it there, read. You can send it there. It is a very good mailing list for new people. You have a question about something. Sometimes people think their questions are too basic and too easy, and then they will actually post it to this mailing list like, no, that's a complex question. Ask on the real mailing list. Every single subsystem of the kernel has their own mailing list. USB, you guys saw the input mailing list. Those mailing lists are very small. They're all open. You don't have to subscribe to them. Anybody can send email to them. They work really, really well. If you want a question from the people who are responsible for the code, who have been maintaining the code, they know it. It's very good in those things. So I suggest using those mailing lists. It's very good. And of course, there, my obligatory penguin picture. So that's it. You guys are all so many patches. Right? So questions? Yes? I couldn't hear that. I'm sorry. If you do a patch for something in the orc arm stuff, do we still send it to you or do we send it to Linux Orb? Send it to, well, run the get maintainer. It'll tell you who to send it to. If the staging, I'm responsible for all the staging stuff. That was me. There's a lot of work to be done in the staging directory. If you don't know what you want to do, grab something there. Otherwise, it'll tell you who to send it to there. Here's your response. Hi. Thank you. You showed us the great powerful tool for blame with get. But what about those lines of code that were written before we had get when we were living under the bitkeeper thing? Actually, bitkeeper is really good. Bitkeeper made us change our development model. We knew what we needed out of the source code control tool. But we've imported all the bitkeeper stuff into get. It's all there. It's just in a different repo. We can track all the way back to the 0.1 release now. Yeah, we've imported it all into get. We've imported the old history. It's all in a get tree. It's a different get tree because we don't care. But you can find it. Yeah. How does your test your changes in the Linux kernel? Do you reboot each time you have changed a line of code? Do I reboot each time I change a line of code? No. I would have no problem with sending that patch off right now if you're changing it. And I hope you wouldn't either because you don't have that driver. So you can't know if it did anything. So you think it's right. It logically looks right. And it compiles right. Send it to me. If you're changing core stuff based on something that you know you want to do, then test it, please. Build it. We see a lot of patches that are sent to us that aren't obviously built because they failed to build. You can't break the build. Every single change in the kernel needs to not break the build. We can bisect things down. We want to find the bug. Every change we need to build. The kernel changes in about five patches an hour, 24 hours a day, seven days a week. Impressive. I don't see any questions anymore. Anybody has any questions, you can email me. Thank you very much.
 My name is Greg Crow Hartman.  I work at Noval, Susie Labs division.  I'm a fellow there.  I do kernel development for them.  And I've been doing a lot of work on Moblin or Goblin.  That's what this is.  This is open Susie version of Moblin.  So it looks a little kind of funny.  That's what it is.  It's a lot of fun.  The talk is online, that location, including the slides  and a big, long article that was written.  So all the words are there.  So you can read it if you want to read it.  So write and submit your first kernel patch.  The Linux kernel last year had over 2,000  individual contributors.  Now half those people only submitted one patch.  Then half the half submitted two.  Half the half the half did three.  It's a little exponential curve.  But those 2,000 people, that 1,000 people that did one patch,  that's good.  We need more people contributing.  After this talk, you guys can contribute.  So there's what?  2,000 people here.  So we'll double our quantity next year.  Awesome.  So first thing in the Linux kernel, even if you don't  want to program, you don't want to do anything, but you  have questions about the source code, anything, the  documentation, how to file.  It tells you everything.  And what it doesn't tell you, it tells you links to other  files, other website, other locations of what you're  curious about.  If there's any question that you have that isn't answered by  that or the other links, let me know.  Let other people know.  My email address is at the front.  We maintain this.  This is a very, very good resource.  You have a question.  It's there.  We write lots and lots of documentation, and nobody  reads it.  But hey, I'm trying.  So what are we going to not cover in this talk?  I'm not going to teach you how to build the Linux kernel.  I wrote this book a number of years ago for O'Reilly.  The Linux kernel in that shell, it's free.  It's online.  You don't have to buy it.  I really get no money if you do buy it.  That tells you how to build the kernel.  It tells you how to install it, how to configure it, how to  do it all.  It's all online, free.  That'll teach you how to install a kernel.  If you can install your own kernel that you built, you're  almost there.  That's it.  It's a very good thing.  So read that book.  I'm also not going to teach you C. I actually learned C at  the time of my talk.  I had Minux in college.  I had to learn C and write a floppy driver as my very first  assignment.  It was hell.  But I loved it.  I did not do good in that class in university.  But I loved it.  It's an allegory.  Very good book.  It's a very small language as far as the specification.  Very, very powerful.  People can call it a portable assembler.  That's true.  It runs on anything.  I've written C code for microcontrollers that had one  and a half registers.  It can be done.  That was a fun processor.  All right.  What are we going to cover?  Here's what we're going to cover.  Talk about Git, the Linux kernel source code control tool.  It's a very, very powerful source code control.  Our coding style, what the kernel does, how to fix a  file once you find what you want to change.  So talk about how to find something to change, how to  generate the patch, and how to email the patch.  That last one gets so many people.  Email clients suck.  Email servers suck.  They like stripping off tabs.  You guys see it.  You're developers.  Convert tabs to spaces.  Spaces to tabs.  Wrap lines.  Don't wrap lines.  Exchange server for Microsoft will not send Linux  kernel patches through it.  It just won't work.  So much so.  Microsoft has now contributed to Linux kernel.  Microsoft has an internal Linux server that they use to  send me patches.  It works great.  Intel has the same thing.  IBM has the same thing.  Novell has the same thing.  No, we don't use Exchange.  We use GroupWise, which is actually worse.  Oh, this video?  Sorry.  Different division.  GroupWise started on the Amiga.  Anyway, so let's talk about Git.  Git is awesome, if you guys don't know about it.  So Git is a Linux source code control tool.  The Linux kernel uses it.  Lots of other people use it.  It's very, very good.  I'm not going to go over how to use it, how to install it,  but I'll talk about how you can use it for the kernel.  It's a very, very powerful thing.  There's really good tutorials online to use it.  So read them.  There's very good books online.  Some of them are open.  Some of them aren't.  There's some very good stuff.  It's out there.  But some things about Git that's really good.  So first off, you have to know where you're going to get our  kernel tree from.  And it's at that tiny location.  It's easier to Google it.  But there.  So you clone the tree somewhere.  So I've cloned the tree, and I'm in this directory.  In my directory, and Git status.  Nothing's going on.  And this is a little tiny, cheap laptop in Git rocks.  It does have a good hard drive, though.  So one thing when you start using Git is you don't want to  be modifying the main branch.  You want to make all your changes somewhere else.  Because you're not Linux, so you're not going to be able to  modify his tree.  He takes patches from other people, and then you pull.  So you don't want to mess with the main branch of  development.  So what we're going to do is we're going to branch.  We're going to Git branch.  So let's make something called Git branch tutorial.  So I've got two branches.  The little star says which one I'm on right now.  Masters the main one.  I really want to switch to the tutorial branch.  So Git, check out tutorial.  And hey, it does bash completion.  Switch to branch tutorial.  And now we're on the tutorial branch.  So anything I do is on my separate branch.  I won't mess with Linux's.  I've got a call.  It's good.  We also want to be on a separate branch because we want  to know what changes we have made compared to him.  Because we want to send all those changes off to somebody.  So we want to know how to differentiate ourselves.  So that's a nice thing to do.  And then we'll always show you what branch you're on.  I'm on the branch tutorial.  So Git branch.  Make your own branch.  Don't be afraid of branches.  They're good for you.  They work nice.  So let's talk about the coding style in the Linux kernel  now, now that you guys know everything about Git.  First off, you guys do a lot of development with other  people.  Why do we care about a coding style?  And it sort of comes down to one thing, your brain.  This is a study done a long time ago.  You guys can read the quote.  But what it really means is your brain sees patterns.  And it's very, very good at pattern-mashing and seeing  things that are out of the ordinary of those patterns.  So when you use the same coding style over and over and over,  the format of stuff goes away.  Your brain can't see that.  You can see the metadata inside.  You see the bugs.  You see the logic inside much, much better.  So only thing that matters about a coding style is it's  consistent.  I don't care where you put your braces.  Your tabs, your spaces.  If you're going to do it for your project, be consistent.  If you're on a project that doesn't have a coding style,  make one.  Well, don't use a good new one.  But make another one.  Yeah, my brain hurts watching the new one.  But that's good.  Those guys know their brain feels good, and their brain  hurts when they write Linux kernel code.  So it works.  You can switch between them.  But be consistent.  Seriously, if you're a one-person project, pick a  coding style and stick to it.  Because you want somebody else to join, somebody else join.  Hopefully you should.  I hope there's no major projects these days without a  coding style.  I hope.  It just matters.  Because the real goal is, I want you to fix my bugs.  And you want me to fix your bugs.  We want other people to read the code.  Reading code is very, very important.  When you first start off in university or learning how to  program, you start writing code.  But when you first start learning how to speak a  language, you don't start writing it right away.  Or music.  You don't start writing music right away.  You read a lot.  Reading a lot is very, very good.  So having code that can be easily read is very important.  The Linux kernel is one of the largest code bases in the  world, largest developed project in the world ever  has happened.  And it's very, very readable.  It's very good code.  It's very easy to understand.  Even at C, it's very easy to understand.  So that's why it matters.  It really matters.  It's all down to your brain.  So what do we do?  We have it.  It's in documentation coding style.  You'll notice that's camel case.  I don't know why.  We don't do camel case.  But in there, it's a very readable document.  It's gotten longer over the years.  People started being nitpicky.  You can get too particular about a coding style.  The best thing is have a few guidelines and stick to that.  When you start getting where you put some other things, it  gets too much.  You can argue, like everybody likes to argue.  So here's our rules.  Use tabs.  Yes, sorry.  Yeah, but it's consistent.  Hopefully you don't do that in your projects.  And I won't contribute.  But you won't contribute to mine.  Use tabs like God intended.  All tabs are eight characters and 80 character line limit.  This last one I hate.  And it's actually starting to go away.  We realize our terminals are not 20 years old.  They're not 80 characters only.  So we do start taking things long.  But the interesting thing about this combination, if  your tabs are eight characters and your code starts going  way over here, and you hit the 80 character line limit soon,  so your code starts wrapping and looking really bad, what  that means is your code is getting too complex.  You should be refactoring it, making it smaller and easier  to understand.  So by sticking to 80 characters is a very good limit on  yourself to make easily to read code.  Means you're doing something wrong in the logic.  It shouldn't look like that.  You shouldn't be running into that limit.  Now long strings, long function names, or long function  declarations you can break, strings you really shouldn't  because you want to grip for them easily.  But so 80 characters is, even though if we do bump into 132,  which we probably will, it's a good logic check.  Means you're doing something wrong.  All right, so people hate tabs.  Braces in the sea, like Kernighan and Richie show,  upper right, lower left, all the way over.  That's it.  There's nothing other to think.  Fun thing, error numbers.  All our error return values are always negative in the kernel.  Zero means true.  That's Unix for you.  We never return a positive number.  Very, very, very rarely return a positive number.  So braces, like that.  What do we do with it?  It's else statement.  Again, wrap it.  There and there.  Report error, go tos.  We like go tos.  Go tos are really important because in the kernel,  we do locking.  You lock because we're doing multi-threaded,  multi-processor stuff.  And when you enter a function, you grab some locks.  When you exit a function, you unwrap some locks.  Report error, if I was to do something,  I want to jump to the place where I unlock everything.  If I was going to return here, I would have to unlock, unlock,  unlock.  And then you forget because somebody  changed the locking a little bit.  It's more important to jump to the end and do that.  Go tos backwards RMS.  I wouldn't recommend that.  The kernel does in a few places, but it's scary.  The scheduler.  I write drivers, not schedulers.  So like that.  That's it.  It's a real simple coding style, real easy.  Now here's the one that a lot of corporations  get upset about.  We don't do it for single argument if statements.  That's it.  Good party.  Single argument if statements, no braces.  We want to keep the lines so you can see it easier.  It's as simple as that.  But if one of these arguments, like the if or the else,  is multiple lines, then you can put the braces on both sides.  It's OK.  That's it.  And the other place for braces in a function,  all the way to the left, do something.  Return zero.  Again, returning zero means true.  Integer is the way we return values.  That's it.  Small variable names, lowercase, underscores,  small, logically easy to understand function names  that do something that say what they're going to do.  No Hungarian notation, no returning,  telling you what type of the variable is.  That's what the C compiler is for.  It will check it for you.  Nothing crazy.  So that's it.  Feel good?  Good.  We have a tool that will check it all for you.  Check patch.pl in the script directory.  It's a fun little tool to run on the kernel itself.  But it'll check your patch.  If you make some modifications to the kernel,  you run this tool on it.  It'll tell you if it's good or not.  If you've done everything you're supposed to do or not.  It's a really, really fun tool.  It's written by a Perl guy, so don't hold that against us.  Check patch.  You can do a file.  You can just run it against a file.  Terse.  Let's pick a file.  Drivers, staging, comedy, drivers.  See.  I have no cash.  There we go.  So it says, if you see at the very bottom down there,  this file has zero errors, 39 warnings,  this is 312 lines checked.  The record so far, I had a driver from a company that  would remain anonymous.  That was 300 lines long to driver, a small driver.  It had 752 errors.  More than twice the number of errors.  Then there was, I don't know the number of warnings,  per line of code.  That was with comment blocks.  We took the logic, and we deleted it and rewrote it.  Anyway, so here's a nice thing.  Warning, braces are not necessary for any arm  in that statement.  So let's make that our change.  So in the drivers staging directory, I maintain that.  It's all the bleeding edge stuff.  It's the crappy drivers that are not  been merged into the kernel pretty properly.  Every place in there, there's a to-do file.  You can read the to-do file if you're curious about what  you want to do.  You don't know what you want to check.  You don't want to know what you want to do for writing  kernel code.  There's a big to-do list in there.  Do one of those things, send us patches, and we're happy.  You do it.  So cleaning up the code to make a check patch clean is  always on that list.  So we'll do that for here.  So let's, mdrivers.  I can't see.  So on this line down here, I'll move it up for the people  on the bottom.  Maybe not.  That's the whole file.  Let's edit it.  Run it again.  And there's one last warning.  Nice.  So hey, we've made a kernel patch.  Seriously.  I mean, people do check patch.  People fix spelling errors.  That's awesome.  We need that.  People removed all the curse words, which damn it was not  fun.  I like those in there.  I'm a hardware developer.  I do embedded.  I used to do embedded, now I do drivers.  So cursing at the hardware is my day-to-day life.  So you like taking it out in the code.  Working around hardware bugs, that's what I do.  All right.  So let's see what it does.  Git, instantly, the whole 600 meg kernel tree told me,  instantly, what was modified.  That's fast.  That's awesome.  Macquarie also does this.  Very nice.  Let's look at the diff.  It shows I subtracted some line.  I subtracted this line.  Hey.  Oh.  Little boingy.  Subtracted that line, added this, subtracted that, added  that, subtracted that, added that.  That's it.  That's a diff.  This is how we do kernel changes.  We make diffs.  Diff you send to the patch tool.  We call them patches.  This is a format.  It's a very common format.  It's been around forever.  Larry Wall made it.  Very, very powerful.  It enables us to send changes through email to other people.  You can read it.  You can review it.  You can look it up and say, hey, that's obviously right.  I removed that, added that.  Good stuff.  Oh, I guess we should build it.  Little thing, if you want to only build a certain sub  directory, you can.  Let me hold kernel.  So let's just build that one.  Builds the file.  Hey, built.  Ship it.  Seriously.  So I maintain the stable kernel releases.  I do all the releases for the stable kernel.  And people ask me, well, how do you test it all?  I said a built, right?  And then all the QA department yells at you.  But I'm serious.  The Linux kernel does not have a test suite.  It's very, very hard to have a test suite for hardware  interactions.  The way my hardware and my laptop works is different than  the way your hardware and your laptop does.  So the best thing you can ever do for us is if you just build  the kernel and tell us if you have a problem, that is our  QA cycle.  We rely on the community to do that.  And that's the only way we can physically do this.  Linux supports more hardware, more different devices than  any other operating system ever.  It currently does and ever has.  It supports more processors than any other operating  system.  Sorry, not BSD.  You guys lost a couple years ago.  Many years ago, five.  And all those drivers work on all those processors.  Linux kernel is amazingly crazy.  It's something that nobody has ever done.  We scaled, we were the number one phone by  Quantity in 2008.  And we were 85% of the world's top 500 supercomputers.  Same year, same code.  That's amazing.  But we do it by everybody testing.  Everybody tests on things.  So if this thing built, it built before, and it builds now,  logically I can look at it, and that's all I can do.  If it runs on my machine, I don't have this hardware.  You don't have this hardware.  So it's OK.  But if somebody else does have this hardware, they can  report the problem.  It sounds bad, but dealing with a lot of these things is  this is the only way you can do it, is use it.  Writing test cases for hardware is hard.  I had a fun bug where if I plugged two USB devices in  while streaming audio out of the third one, then I could  reproduce the bug.  You can't automate that.  I have this giant box of USB devices that I test with.  It's fun.  So OK.  So we made the patch.  So let's commit it.  So we're going to commit.  We're going to make a change into our Git tree.  So Git pops up your favorite editor.  Mine's the one true one.  No, I don't care.  You can do whatever you want.  You don't tell me what to do.  I don't tell you.  OK.  So we're going to write a commit message.  So the good thing about a commit, well, let's show you  an example.  Here's a commit.  So this is what's in the kernel tree.  You can look up this commit.  The very first line on the top, want to make a nice short,  succinct summary of what this does.  In the short log, this will show up.  So it's USB OTG, which is on the go.  That means USB is in the client itself.  So Linux is running out there.  Fix the bug on a remove path without transceiver.  Looks nice.  Nice, short, succinct.  Then we have a few sentences.  This one just says, hey, the scattered driver's removed.  No transceiver find.  It was a bug.  And then we have a signed off by.  Explain signed off by what we do in a little bit.  And then that got sent to the subsystem maintainer for USB  on the go, which is David Brunel.  He said act.  Looks good to him.  He sent it off to me.  I'm the maintainer of USB.  I say I signed off by it.  And then I got it into Linux's tree.  So that's that.  There's the patch.  It removed.  We want to actually test if X is there or not before we  access it.  Otherwise, it would have been a nice little oops.  And that's it.  That's what the patch.  So succinct line, summary of what it does, who wrote it?  But that's signed off by.  Let's see what that means.  When we say signed off by, we are agreeing to this.  We have something called the developer certificate of origin.  And it means this.  You guys can read that.  You made the change.  You based it.  Or you based it on somebody else's change, which was a  compatible license.  Or it was provided by me by somebody like that.  And I didn't touch it.  So somebody sends me a patch.  And it's public.  This is what in the Linux kernel.  So every single line of the Linux kernel is reviewed by  at least two people.  And they sign off on it, saying legally this is it.  It's the best audited body of code in the world.  You can say who modified this line.  And it'll tell you.  So signed off by is a very good thing from the legal  standpoint.  We also do it as the path of blame.  If this patch breaks something, you go, hey, Greg,  you broke it.  David, you acknowledged this.  And Robert, you're the one who really is responsible.  So all of us take ownership of it.  If my name is on a patch that breaks something, it's up to  me to fix it.  Contribution is public.  We also don't take anonymous contributions to the Linux  kernel.  If I know you're anonymous, I cannot take it.  If I don't know you're anonymous, I can take it.  It's just a legal thing.  That's all we do.  That's all.  And companies agree to this.  You own your copyright on any files you have.  Some countries, like Europe, are not allowed to  absolve your copyright.  So it's very good.  You own your copyright.  Your company can own the copyright.  Everything is great.  That's what signed off by means.  So we did something.  So I'm going to say, in the staging directory, the  column D drivers, the SSV DNP driver I fixed, a brace.  This one's kind of obvious.  And I'll say, signed off by.  I have a little macro that does that.  And let's commit it.  Boom.  You can see, if you do get logged, the very first thing,  my patch.  Do that.  You can see if you do get show.  There's the patch, in patch format, who authored it.  When it was authored, the commit ID.  You can see get show pretty equals fall.  Author and who committed it to a tree?  Because authorship is who wrote it, but it might not be  who committed it to a tree.  You send a patch to me to send off to somebody else.  I'll end up committing it to get somewhere.  But you authored it.  Authorship is very important.  We preserve authorship everywhere.  So we don't have really good ways of two people wrote a  patch, but that's usually pretty rare.  Authorship's very important.  So there.  Patch.  Cool.  So get diff.  Show the diff.  Commit.  Show it.  Oh, format patch.  Let's make this patch.  It is a patch, so remember we had two branches.  Tutorial master.  So we want to take this patch and send it off to somebody.  But we have to make it into a patch.  So we have a nice tool, a nice thing, get format.  And I want to say I want to do all the patches.  If I've done more than one, I could just do it for one.  I want to do from master to tutorial.  And hey, it made a patch.  It made one file.  So if I look at this, it turned it into an email.  Imagine that.  This is good.  It says, when I wrote it, date, subject, fix the coding  style, signed off by, what was modified, looks pretty, looks  nice.  Perfect.  This is great.  Now you have a patch.  Now what do you do with it?  This is hard.  So email clients, GUI-based email clients, will corrupt  these.  It's not very good.  We have a whole file in the kernel and documentation  directory called email-clients.txt how to  configure your email clients to send patches, how to  configure Gmail to send patches, how to work around  Thunderbirds issue, work around all these issues.  Kmail works really well.  Evolution, OK.  I use MUT.  MUT works great.  Send mail?  You can pipe it to send mail?  You can?  Or you can do get send mail.  But wait, who do you want to send it to?  Right?  You've got to know who to send it to.  So we've got something fun.  We even wrote a script for it.  Get maintainer.  And you can send it a patch.  Oh, wait, wait, wait.  We want to do Scripps check patch.  It's good.  You can send it off now.  OK.  I've actually done this and it failed.  Don't laugh.  Get maintainer.  So there's a nice script.  It goes and looks at the kernel tree.  It looks at the maintainer's file.  There's a maintainer's file in the directory to who  maintains what.  And looks at who's actually committed to what file.  So if you ever touch a floppy driver, tag you're it.  It says to send it to Greg, which is me.  Send to bills, modified it.  Test this, modified it.  And then to mailing lists.  Because you want to send to mailing lists, we do all our  development in public.  So those are the people I want to send this email to.  So let's send the email.  Oops, I want to say to me.  That's not good.  I'll copy to osl.org and copy the next kernel.  Now you can do something called, oh, what is this?  There's an option that you can edit.  If you're sending multiple patches, you can say start  up patch.  The first patch you want to send is a little summary of  everything.  So you want to say, these patches are going to do this.  I'm sending up one file, and you don't really need a  summary.  This one is so simple, it's self-explanatory.  So if you're doing these kind of changes, and I really  recommend you do these changes, just send me one patch.  But if you're sending more than one patch, or a patch that  depends on another patch, then you need to tell me what  order in which to apply them in.  Patches for Linux kernel need to do one thing only.  Don't be a replace this subsystem.  We want to see your work.  Like your old professor used to say for math, show me your  work.  Show me the individual logical steps of what you did.  They can be in order.  So one depends on the other, depends on the other.  And that's really good.  Linux kernel works on the fact that other people review it.  You have a 15 patch, patch set.  Patch number five didn't do something quite right.  So we'll apply the first four, and then you'll take the  review and work on the rest of them.  And that's work.  It's an iterative design process.  I wrote the Linux driver core, along with somebody named  Pat Michelle.  When we came up with this idea, we wanted to unify the way  drivers worked in the two five series.  Some other kernel developers saw all the work we were  starting to do.  They said, no, we can make that and make it even a more  base type, sort of a common type in the kernel called k  object that all other types of objects can do.  And then we realized, hey, that's reference counting.  And then we can refactor that and make that a smaller thing.  So we have a very, very flexible type system in the  kernel.  We do multiple inheritance object overloading in C.  Virtual functions, as fun.  Some days I wish I had a C++ compiler.  So but it's showing your work, seeing other people seeing the  idea and saying, no, it could be made better.  Recently, Google's been in the news for not getting their  code into the kernel because they dropped big chunks on  the kernel.  And they didn't go through the review design review process.  We said, hey, but wouldn't be great if you tweaked this and  did this this way.  And you can't just drop big chunks.  You can add a whole new driver?  That's fine.  You're not touching anything else.  Add a new file system?  Great.  If you want to change the core VFS like RyzerFS4 wanted to  do, no, it's not good.  You have to go through review process.  Changing little things in drivers is very simple.  Changing things in the core kernel isn't so simple.  But that's good.  You don't want us to be able to modify the core kernel that  everybody uses as easily as you can do other things.  But we should always be able to take spelling fixes for  things.  So let's send the mail off.  So it'll ask me, who do I want it to come from?  Hey, it'll come from me.  It guesses based on your IDs.  Do that.  And if you want to do a reply to, it'll do that.  I don't want to do that.  And then it'll ask me, hey, I'm going to send this to this  person, copy these people.  It's going to look like this.  Because it looks through the email, guess, is this OK?  It's nice.  I'll say yes.  It talks to my servers halfway around the world.  And it worked.  Result OK.  And then we do a little notification get.  We'll tell you something.  Yeah.  How does that send the email number with server icon  here?  It's equal to 8.  My internet is 1.  Yes, how does get send mail know what to do?  There's a zillion options.  I have in my get config, I say my SMT server is my local  SMMTP.  And then that has its configuration that knows  where to go.  So if you Google or you look at the man page for send  email, it'll do lots of things.  It'll tell you how to connect to Gmail.  You can use Gmail remote IMAP to do this, to send patches  off.  You can point it to somewhere else.  You can point to your local send mail.  It's extremely configurable that way.  It's very good for sending spam, too.  It was based on a Perl script I wrote a long time ago that  actually I have a rule in spam assassin that's named after  me.  Though I used to send patches out, but other people got a  hold of it.  So that's it.  So send email off.  We'll look in a minute.  My server doesn't refresh that fast.  See if it really got there.  So get maintainer.  Get maintainer is fun to know who to send the patch to.  But it's also good if you think there's a problem in  this file.  So let's pick a file in the kernel.  Pick a file.  Give me a file.  Keyboard, which one?  All right, drivers, head.  Head, easy key.  OK, yearzy is the head maintainer.  Peter worked on the file.  Yearzy Slavi also worked on it.  And you want to send it to the input list and the  external.  Boom.  So if you have a question about that file, hit them all.  The Linux kernel has been known to be a not nice place to  play.  But people respond well, hopefully in ways that might  seem aggressive at times.  But if you've ever seen internal email lists on  technical people or companies, this is, the  Linux kernel is nice.  The thing, people will critique your code.  They won't yell at you, hopefully.  You don't go and say, wouldn't it be great if you do this?  You show code.  You do things like that.  The best way to get somebody to do work for you, this  works once a year.  Take advantage of it.  But don't abuse it.  Make some changes to the kernel that you know are wrong.  And then submit it.  Send it to the maintainer.  Send it to the mailing list.  The maintainer will go, oh, crap, that's wrong.  I can't take that, but I'll do it right.  Because I have to do it right because that might go in  instead.  So you can do that.  But here, you can see who wrote that.  Each thing.  So if you had a problem with that file, mess with the  yearsy.  I'll do the same thing.  Stage R, driver's head.  So before I said, remember, we can see who wrote what line of  the code and what did it.  There you go.  You want to see who wrote every single line, who reviewed  it.  This all came in as one big patch.  Oh, here's a change from Peter.  And then I can do get show that commit.  And boom.  I can see that Peter changed something to be a  emit function.  So there.  And two people reviewed that line.  I mean, that's an extremely, extremely powerful thing.  Get is very good.  And look how fast that.  I mean, this is a cheap little laptop.  It worked really good.  I just picked something random.  Anyway, it gets awesome.  I'll refresh my mail and go to the next thing.  So here's a checklist for what you need to do.  There's actually a checklist in the  documentation directory.  But it makes sure it builds.  We almost forgot that one.  Makes sure it's from the right person.  Some companies don't let you contribute to the external.  So make sure you contribute from your home email address  instead.  We track who writes what in the kernel.  We do a report every year through the Linux Foundation.  If you send a patch in and I can't figure it out by your  domain, you'll receive an email from me in a few months.  Just asking.  You don't have to respond, but we try and keep track of it.  We want to know who's doing the work.  Other people reported 80% of the work done in the Linux  kernel is done by companies, paid contributions.  Some people think it's a bad thing.  I think it's really good that 20% is done by people who  aren't paid.  This is their hobby.  The problem with that 20% is if you start doing patches, you  will get hired, and that'll be your job.  This used to be my hobby.  Now I have no hobby.  Other kernel developers have known to burn out and start  other hobbies, and then they turn that into a company, and  then they go back to kernel development.  It's happened a lot.  So make sure a concise subject.  Explain the patch and signed off by.  That's it.  This is a very, very simple thing to do.  Come on.  Anybody can do this.  Literally, anybody.  Let's see if I can show it.  Aha, there's my patch.  It sent to me, came to me.  Cool.  And there it is.  Not going to apply it.  So you send off a patch.  Somebody said, how do you know what to do if nobody  responds back?  And that's a good question.  Give people a week.  Some people travel a lot.  If they don't say anything in a week, send it to them again.  Be persistent.  You're not being annoying.  You're being persistent.  It's OK.  I want to be reminded that me, as a maintainer, I'm not  doing my job.  Send it off.  Keep bugging us.  Persistence is the key.  It literally is.  It really is.  Just be persistent.  That's all I can say.  It works really well.  My inbox.  Yeah.  Checklist.  And kernel newbies group.  If you're afraid of the next kernel and you're afraid of  asking a dumb question, kernelnewbies.org, very,  very good resource.  Wonderful Wiki explains what is in each kernel release in a  nice, concise summary.  There's an IRC channel that's awesome.  It has about 600 people in it, but nobody talking.  The problem is people show up and they're like, ah, it is  not for off-topic stuff.  You ask a question, it will be answered.  I'm in there.  A lot of the kernel developers are in there.  It's a really good spot, that IRC channel.  They have a mailing list.  There's only one stupid question you can ask on this  mailing list, and that's a question that was already  asked this week.  Read the archives.  Just read the archives for a week.  If you can't find it there, read.  You can send it there.  It is a very good mailing list for new people.  You have a question about something.  Sometimes people think their questions are too basic and  too easy, and then they will actually post it to this  mailing list like, no, that's a complex question.  Ask on the real mailing list.  Every single subsystem of the kernel has their own mailing  list.  USB, you guys saw the input mailing list.  Those mailing lists are very small.  They're all open.  You don't have to subscribe to them.  Anybody can send email to them.  They work really, really well.  If you want a question from the people who are responsible  for the code, who have been maintaining the code, they  know it.  It's very good in those things.  So I suggest using those mailing lists.  It's very good.  And of course, there, my obligatory penguin picture.  So that's it.  You guys are all so many patches.  Right?  So questions?  Yes?  I couldn't hear that.  I'm sorry.  If you do a patch for something in the orc arm stuff, do we  still send it to you or do we send it to Linux Orb?  Send it to, well, run the get maintainer.  It'll tell you who to send it to.  If the staging, I'm responsible for all the  staging stuff.  That was me.  There's a lot of work to be done in the staging directory.  If you don't know what you want to do, grab something there.  Otherwise, it'll tell you who to send it to there.  Here's your response.  Hi.  Thank you.  You showed us the great powerful tool for blame with  get.  But what about those lines of code that were written before  we had get when we were living under the bitkeeper thing?  Actually, bitkeeper is really good.  Bitkeeper made us change our development model.  We knew what we needed out of the source code control tool.  But we've imported all the bitkeeper stuff into get.  It's all there.  It's just in a different repo.  We can track all the way back to the 0.1 release now.  Yeah, we've imported it all into get.  We've imported the old history.  It's all in a get tree.  It's a different get tree because we don't care.  But you can find it.  Yeah.  How does your test your changes in the Linux kernel?  Do you reboot each time you have changed a line of code?  Do I reboot each time I change a line of code?  No.  I would have no problem with sending that patch off right  now if you're changing it.  And I hope you wouldn't either because you don't have that  driver.  So you can't know if it did anything.  So you think it's right.  It logically looks right.  And it compiles right.  Send it to me.  If you're changing core stuff based on something that you  know you want to do, then test it, please.  Build it.  We see a lot of patches that are sent to us that aren't  obviously built because they failed to build.  You can't break the build.  Every single change in the kernel needs to not break the  build.  We can bisect things down.  We want to find the bug.  Every change we need to build.  The kernel changes in about five patches an hour, 24 hours a  day, seven days a week.  Impressive.  I don't see any questions anymore.  Anybody has any questions, you can email me.  Thank you very much.
WriteandSubmityourfirstLinuxkernelPatch_4_0_131.png WriteandSubmityourfirstLinuxkernelPatch_4_132_179.png WriteandSubmityourfirstLinuxkernelPatch_4_180_1655.png WriteandSubmityourfirstLinuxkernelPatch_4_1656_2675.png WriteandSubmityourfirstLinuxkernelPatch_4_2676_2759.png WriteandSubmityourfirstLinuxkernelPatch_4_2760_4679.png WriteandSubmityourfirstLinuxkernelPatch_4_4680_6575.png WriteandSubmityourfirstLinuxkernelPatch_4_6576_6683.png WriteandSubmityourfirstLinuxkernelPatch_4_6684_6779.png WriteandSubmityourfirstLinuxkernelPatch_4_6780_7583.png WriteandSubmityourfirstLinuxkernelPatch_4_7584_7631.png WriteandSubmityourfirstLinuxkernelPatch_4_7632_7823.png WriteandSubmityourfirstLinuxkernelPatch_4_7824_7871.png WriteandSubmityourfirstLinuxkernelPatch_4_7872_8231.png WriteandSubmityourfirstLinuxkernelPatch_4_8232_8783.png WriteandSubmityourfirstLinuxkernelPatch_4_8784_8831.png WriteandSubmityourfirstLinuxkernelPatch_4_8832_10271.png WriteandSubmityourfirstLinuxkernelPatch_4_10272_13859.png WriteandSubmityourfirstLinuxkernelPatch_4_13860_15659.png WriteandSubmityourfirstLinuxkernelPatch_4_15660_20795.png WriteandSubmityourfirstLinuxkernelPatch_4_20796_25379.png WriteandSubmityourfirstLinuxkernelPatch_4_25380_30011.png WriteandSubmityourfirstLinuxkernelPatch_4_30012_30059.png WriteandSubmityourfirstLinuxkernelPatch_4_30060_30395.png WriteandSubmityourfirstLinuxkernelPatch_4_30396_34475.png WriteandSubmityourfirstLinuxkernelPatch_4_34476_35339.png WriteandSubmityourfirstLinuxkernelPatch_4_35340_35507.png WriteandSubmityourfirstLinuxkernelPatch_4_35508_35579.png WriteandSubmityourfirstLinuxkernelPatch_4_35580_35735.png WriteandSubmityourfirstLinuxkernelPatch_4_35736_35819.png WriteandSubmityourfirstLinuxkernelPatch_4_35820_36407.png WriteandSubmityourfirstLinuxkernelPatch_4_36408_36455.png WriteandSubmityourfirstLinuxkernelPatch_4_36456_36719.png WriteandSubmityourfirstLinuxkernelPatch_4_36720_47543.png WriteandSubmityourfirstLinuxkernelPatch_4_47544_47879.png WriteandSubmityourfirstLinuxkernelPatch_4_47880_50603.png WriteandSubmityourfirstLinuxkernelPatch_4_50604_50855.png WriteandSubmityourfirstLinuxkernelPatch_4_50856_51119.png WriteandSubmityourfirstLinuxkernelPatch_4_51120_51599.png WriteandSubmityourfirstLinuxkernelPatch_4_51600_51659.png WriteandSubmityourfirstLinuxkernelPatch_4_51660_51707.png WriteandSubmityourfirstLinuxkernelPatch_4_51708_53735.png WriteandSubmityourfirstLinuxkernelPatch_4_53736_53807.png WriteandSubmityourfirstLinuxkernelPatch_4_53808_54887.png WriteandSubmityourfirstLinuxkernelPatch_4_54888_54935.png WriteandSubmityourfirstLinuxkernelPatch_4_54936_54995.png WriteandSubmityourfirstLinuxkernelPatch_4_54996_57263.png WriteandSubmityourfirstLinuxkernelPatch_4_57264_58319.png WriteandSubmityourfirstLinuxkernelPatch_4_58320_58667.png WriteandSubmityourfirstLinuxkernelPatch_4_58668_58907.png WriteandSubmityourfirstLinuxkernelPatch_4_58908_58955.png WriteandSubmityourfirstLinuxkernelPatch_4_58956_59807.png WriteandSubmityourfirstLinuxkernelPatch_4_59808_60095.png WriteandSubmityourfirstLinuxkernelPatch_4_60096_60143.png WriteandSubmityourfirstLinuxkernelPatch_4_60144_60791.png WriteandSubmityourfirstLinuxkernelPatch_4_60792_62015.png WriteandSubmityourfirstLinuxkernelPatch_4_62016_62129.png