 So, good morning everyone. I am Saiji and I am an undergrad from India and currently I'm studying at Stony Brook University as a graduate student. So, I have around 50 patches merged into the Linux corner during the course of my internship. Has anyone heard about the Outreachy program? So, it's a good initiative by the Linux Foundation where they provide open source internships to under-represented communities and women. So, that's a great starting point for women if you want to get started with contributing to the Linux corner. I myself interned under Jonathan Corbett who is a maintainer under the Linux torwads. He also happens to be the documentation maintainer. So, I wrote a couple of scripts for automating documentation in the Linux corner. So, that's something about me. The Linux corner actually all known is one of the biggest and fastest moving open source project today. It has more than 50,000 files and more than 2 million lines of code. So, how does Linux torwads manage such a huge project with such a high scalability? So, what the Linux community follows is a maintainer model. Developers from all nukes and corners of the world contribute chunks of code called patches to file or driver maintainers. And these maintainers then contribute, they collect all these patches and then forward it to another hierarchy of maintainers called the subsystem maintainers and who then collect all of these patches and then forward it to Linux torwads. Linux torwads then collects all these patches and merges them into his version of the tree and that's how we get a new release. So, that's how we are able to collaborate, collaborate, work from so many developers worldwide. These developers can be anything ranging from paid employees from Google, IBM, etc. And they also can be, you know, individual contributors, like me. So, most of my talk will be about delineating the steps that are required to get your first patch in. So, the prerequisites are pretty straightforward. It's just a good knowledge of C programming and a version control system that is key. It also requires working knowledge of operating systems. You might get that by reading a book called the device drivers. That's a really good book if you want to get started with Linux kernel hacking. So, the step one is having a Linux distribution. You can have any Linux distribution of your choice but the commands for this talk are more relevant to Ubuntu or Dubin. The setup tools are an editor. You can get them, get it or any editor of your choice. You need an email client called mud. I personally use mud because Gmail kind of messes up with the formatting of your patches. So, that might result in getting valuable patches rejected. And of course you need it. So, the step two is downloading or cloning the kernel repository. I have contributed to the staging tree which is maintained by Greg Rowe Hartman. So, the reason why I'm suggesting that you contribute to this particular tree instead of directly contributing to Linux tree is that Greg is open to bigger level patches. In the beginning you might want to send in 4 cleanup patches or fixing minor bugs which all maintainers are not open to accepting. So, this is a very good place to start. Then you need to copy your current config into a file called dotconfig. Using the command that I've shown. If you go to get kernel staging and run the ls command, you'll see a lot of different folders beside. There are folders for drivers, file systems, IPC, there's security, there's multimedia, etc. So, you need to do a bit of exploring and go inside these folders to see what your interest lies in and then try to understand the code a little bit. The next step involves compiling your kernel. So, you do that with the main jox command where x stands for the number of cores that your system has. So, it can be two or four or whatever your system has. Next, you need to install the kernel. You do that using the make modules install install command. This might take some time. It might take like two or four hours or so. The step four. So, the step four involves making a branch. So, here I've created a branch called first patch and checked into that branch. Next, you need to update your kernel. So, I do that using the fetch origin command and I'm doing a rebase of origin slash staging testing. It's really important that you make changes on the updated kernel because if your kernel is not updated, then a maintainer might say, hey, your changes are correct but it's not on the updated kernel. The next step is actually making code changes. So, we'll get back to this a while later. Let's just pause this right now. Once you've made the code changes, you need to recompile and make sure that your changes do not break the original kernel code. So, when you send in a patch, it's already considered that you have recompiled it and make sure that your code is error free. Yeah. So, now the step five involves committing and actually sending in your patch. So, these are really basic good commands. So, you add your file, you commit your file and you use the good format patch to make a file with the dot patch extension. So, here I have one xyz dot patch. So, this is the file that I have generated using the format patch command. If you can see the head carrot symbol is actually my second last commit. So, what I'm asking you to do is make a patch out of the most recent commit that I have just committed. One more thing to note here is the hyphen s flag. So, the s flag is basically the sign of by flag. The sign of by flag is followed by your name and your email address. So, what it means is when you append the sign of by flag, it means that you have basically read through the developer certificate of origin, which has a few clauses related to compliance and your patch will not get accepted if you don't have the sign of by flag. Let me give you a few example patches. So, this is a very simple patch that I have submitted some months ago. It basically replaces the tedious left shifting of one using the bit macro. So, the bit macro is an existing macro in the kernel and sometimes developers just use the tedious left shifting of one instead of using this macro that already exists. So, the patch structure is look somewhat like this. The first line has the path to the file that you have changed. So, in my case, it's staging media and davency vpfd. So, this is the file that I have changed. It has to be separated with colons and it has to be followed by your commit message concise message saying what your patch is doing. After that is a blank line and after that follows a description of what your patch does and why you're doing that. So, if you read through it, I have mentioned something called a coxsignal script. I'll be shortly demoing how these scripts work. So, coxsignal is basically a pattern matching and transformation tool. So, it kind of helps you gain hints towards what you can change. So, these are basically scripts that you run over your code and then you understand what needs to be changed. I'll give you a clearer idea. So, I've just mentioned the script and as I mentioned, there's my signed off flag. There's my name and followed by Greg's signed off flag who was the one who merged my patch. And after that you have a div stat of your patch. So, the red lines prepended by a minus sign are the ones that I have deleted and the green lines are the ones that I have added. So, as you can see one less and less than zero has been replaced with bit of zero which is a macro in the code. So, I hope this gives an idea of what the structure of basic patch looks like. Yeah. So, once your patch is ready, it's time to send in the email. Okay. So, you can use get send email as well, but I have used mud. So, when you type mud have an edge and then the path to your patch onto the terminal, it opens your mud terminal and then you can mention the email IDs that you want to send the patch to and this basically attaches the patch onto the email. Now, you might ask, how do I move to send the patch today because I don't know who wrote the file. So, I don't really know who is responsible for merging my patch. So, the answer is in the scripts folder, there's a pod script pod get maintainer.pl and if you run that script using these particular flags, I have uploaded my presentation so you can probably copy all these flags from there and followed by a file. So, over here it has been air followed by sound.c and the result here shows Greg. So, he was the one who wrote the file. So, it will probably give you a comma separated list of all the maintainers that are responsible for the file and also, it's better to CC the mailing list that's responsible for that particular file. So, there are different mailing lists. For example, IIO has a separate mailing list. You can also CC the main Linux kernel mailing list. So, that's it. That's just how your particular code goes to the maintainers of the patch. Now, let's see what you can change in the country because that's generally the question that beginners ask. Like, I know I have seen the code but I don't really know what to change. So, as I said you can do a bit of exploring and look at different drivers and try to understand the code. A good place to start is by running a script called checkpass.pl. So, checkpass.pl decides in the script folder and if you run this particular script over private slash staging slash whatever, you'll get a number of these coding style bugs that exist in those particular files and then you can just manually go to that particular file, make a change to that particular file and send in a patch for that. So, checkpass.pl is basically used to check patches but you can run them on the kernel files as well. The kernel community is kind of nitpicky about coding styles and that ranges from something as trivial as indentation or placement of braces etc. So, here's a link linking to a documentation for the coding styles. You can have a look and find instances where the code is not following these coding styles and submit a patch for that. That could be a good place for starting your first patch. In fact, the documentation in the kernel is itself a good area to contribute. So, I interned with Jonathan Corbett who was a documentation maintainer and it's quite funny he kind of relates to the documentation in the Linux kernel with his kid's bedroom. So, there's a lot of valuable stuff in there and there's a lot of stuff but it's all messy and it's all unorganized. So, documentation has a really good scope to send in patches. So, that's just another example patch submitted by me. So, as you already know, the first line is the comment passage wherein I'm removing a type def to a particular structure. So, type defs are generally frowned upon and the Linux guide says that you should use only structures. So, I write that from the documentation and I send in a patch for that. Yeah, so I have my send off by flags and then I am subtracting the type defs and replacing it with actual structures and then there are some cascading changes as well. Yeah, so there's just another patch probably my first patch. So, how I got to this patch was I checked in my good logs and I found a commit that removes that replaces a function with a particular function. So, the function that was replaced was the definition of that function was not yet removed although this function was not really called anywhere. So, I realized that I should probably go ahead and delete this function because it's not used anywhere. So, although make sure you do a quick grip and check for sure if this function has not been called anywhere. So, yeah just delete a particular, when deleting a particular function is counts as a patch. Some coding style dimensions used by the Linux community. The first is not just restricted to the kernel which is using meaningful names. The second one is that the kernel does not use lines that are more than 80 characters. So, always break up your lines after 80 characters. There are quite a few rules surrounding indentations, spaces and places which you can stay check in the coding guide. Like we just saw always avoid type defs. And there's also standard commenting style you cannot use to forward slashes for commenting. They have a particular block structure and they follow something called as kernel doc comments for coding for commenting. And yeah as we saw earlier always use existing macros and not reimplement those macros. So, I mentioned coxson and earlier this was developed by Julia who is a kernel coder herself. It's a pattern matching and transformation tool. So, what it means is if you look at this script and you look at what I have subtracted and added, you'll see that I have subtracted size of e divided by size of star e which basically gives you the size of an area where e is my area. So, I am subtracting that and using an existing macro called area underscore size of e. So, this is my .cocc file and when I run this particular script over my .c files or over you know multiple .c files in the kernel, basically it gives me instances of where developers have used the huge formula and it gives me readymade patches of text replacing the first line with the second line. So, I can either you know manually go to the kernel and change this or there's also an in place flag where it you know does it all for you. There's also this file called foo.coxy for example. So, what this does is if e is your expression e not equal to 0 is replaced by e not equal to null. So, this is what foo.coxy does and if you want to run this particular .cox file over your .c files there are two methods to run that. The top two boxes use something called made coxy check and the bottom two boxes use espatch. So, let me show you something let me show you how coxinal works. So, if I go to my terminal so if you see the fourth line yeah. So, I'm subtracting e equals null and replacing it by not of e. So, basically the current coding style says that e equals equals null is not a very good way of you know evaluating expressions and is a better to replace it with a shorter not of e. So, now if I run this null.coxy file using the espatch command over all the files in my drivers folder you'll see it's handling all of these files and also giving me like these ready made patches. So, if I just intercept this yeah. So, as you can see here it's giving me a subtraction of this expression and replacing it with this particular expression yeah. So, instead of this if I add the in place. So, instead of this if I add the in place command it'll automatically change these files for you and you don't need to manually go ahead and change it. It's kind of a risky option because it might lead to some false positives but it's better to just you know manually go ahead and correct those yeah. So, another good source of getting hints to what to change in the kernel is reading the kernel mailing archives you can go to linuxkernel.org and read all those mailing archives and get some inspiration as to what you can change. You can also go first update your kernel and then go through a bit log to see historic commits. Also if you do a grep of to-do you'll find that there are many instances where developers have written to-do's and what needs to be done into that particular file and left it like that. So, you can just grab it and you know find what has to be seen in that particular file that's another source. There are a couple of other tools apart from coxnell that help you detect bugs. Spires is one of them. It helps you detect bugs related to engineers or address spaces, stamps, etc. There's also a tool called match which uses spires as a seed pusher and it is basically useful for detecting bugs related to buffer road flows or something like use after free or some bugs related to locking cancels. You also put article surrounding smash if you're interested. Yeah, so once you have sent in your patch you might you might be asked to revise your patch. So say a developer or a maintainer replies to your patch saying that hey this this needs to be changed or this is not quite correct. So how do you reply to that particular maintainer? All of these conversations or on communications take place via email and you have to be very careful while communicating because as you can see like you cannot really talk post on the questions and you have to reply in line. So if you see the text above the blue line that's the wrong way and the text below the blue line is the correct way. So Mark asks three questions to John in the first example. He says do you want to go out to lunch tomorrow? What's your favorite pizza? And you're paying the stand right. And to that he replies the line in the board. Lunch tomorrow sounds great. Let's keep it simple and get a pepperoni pizza. But if you notice he forgot or did not answer the third question. So that's basically the bug the problem with this kind of approach. The second example is what how is how it should be. So as you can see John has replied to each question each question after the answer. So that kind of saves the viewers time and also keeps the conversations more organized and easy to follow. Yeah so now once the maintainer asks you to change something what you do is you go you go to your local repository you basically make a version two of your patch. So if you see after the patch tab there's a v2 which stands for version two. Just ignore the one by two. The one by two is something like if you send a patch set or a series of patches it's the first patch out of the two patches. If you see below the sign of flag there is a change log which is mandated. So changes in v2 are say make the comment message clear or something like that. And then you need to make multiple versions as the maintainer might tell you to. So v3, v4, v5 and so on can follow after that. Yeah so that brings us to the end of the talk. Here are a few resources that I found useful. ConanUBS.org has a first patch tutorial which I think is the best resource for submitting your first patch. Of course there's lwn.net and the Linux kernel mailing list is also a good resource. I think historically there was also a challenge called the Utip-tooler challenge but I think it kind of closed right now. So anyway that was a really good source of learning as well. Yeah so that's it for me. Thanks for coming. If you have any questions and you're for a while and you can also reach out to me on my email address. So yeah thanks. Thanks for listening.