 Welcome to that Ricci Kernel Internship Report. We are recording this today. This is April 3rd. We're recording this ahead of the OSS Summit in Vancouver next month. The last time we were at OSS Summit was in full wall of 2021, when we also recorded for the Seattle Summit. Today I have with me interns from the last two years. I have Deepak Vama, Jayhee Park, Karolina Stolerek, Rebecca McKeeva, and Savin Jagayeva. We also this time have mentors with us. David Hildebrand, Ira Weini, Mike Rappapour, Rupa Prabhu, and Stefano Gribio. So we've brought our own virtual audience with us today who will be able to ask questions and make comments on the intern presentations. And maybe at the end we'll have time for them to offer some of their reflections on being a mentor for Outreachy. I'll give a brief overview of the Outreachy program and then we'll go right into the interns present in their work. So the Outreachy program, you can read all about it at outreachy.org. It is a program across all open source and the Linux kernel is one of the communities that participates in it. They open the program to anyone facing underrepresentation in the technology industry of their country. And applicants apply, interns who are accepted do get a part pay to stipend. The entire program is remote and we do this twice a year. Okay, we have five interns present in and we're gonna start out with Deepak presenting on his Coach NL project. All right, well, thank you. Yeah, my name is Deepak Varma. I've been part of the Outreachy December 2022 cohort as an intern and worked on the Linux project, Cox NL cleanups in the Linux kernel. And as part of this project, my mentors were Sorab Sengar and Praveen Kumar. So talking quickly about the Cox NL software itself, it's a program matching and transformation engine. You can get the details at this particular location. The slides will be made available to you so you can go click and read more about Cox NL at this particular URL. It's a software that's pretty well integrated with the Linux kernel code base. It primarily is used for resolving collateral evaluations, smart identification of code patterns, bug identification, and it can also be extended to fix some of the bugs as well. There are Linux patches that can be automated, automatically generated using this particular software and they can be validated and applied to the code for automatic resolution of the bugs. It's basically based on cinematic patch scripts. These are external script files written in simple text editor and then can be clubbed integrated with the Cox NL software to scan through the code and find the different areas of the code that needs attention. These patches can be added. They can be edited just like any other Linux kernel patch. So it starts closely integrated with the Linux kernel code base. These patches can be improved and they can be submitted just like any other Linux patch to be part of the Linux code base. The core development team for Cox NL software is comprised of, I worked with Julia, Laval, Thierry, Martinez, Nicholas Palick as part of my project, but there are many other contributors who regularly contribute and keep evolving this particular software. It's open source software, so a lot many contributors are there. At the moment, there are 72 semantic patches that are part of the Linux kernel code base and I have extremely worked with a lot of these. I almost all of these as part of my outreach project. Moving on, talking quickly about my outreach project. The objective of this project was to improve the Linux kernel code base, the help of Cox NL software. That was a primary objective as far as the project itself is concerned. And also I was required to write blogs on utilizing these semantic patches so that in future if working with the semantic patches needs to be understood well by any new interns or anybody they can't refer to these blogs. So these were the two defined objectives for my project. And in terms of my own benefits, I was expected to be learning how to work with the Linux community, understand the Linux code organization, understand the development process that is being followed as part of the Linux kernel development. And also understand the Cox NL software and how it can be applied to the Linux code base. So these were the benefits that I was targeting as part of the OCG internship. So yeah, my internship started on 5th of December, 2022 and it ended on 3rd of March, 2023. It was a pretty exhaustive 12 week long internship. And during this internship I submitted 115 patches. Again, it's not a number game. I think quality always weighs more in Linux kernel than the quantity, but just to summarize in terms of to describe the success of the project, the total patches that were submitted was 150. That around 30 patches that are still either in discussion or that need the maintainers to approve those. 54 patches that have been accepted or applied by different kernel tree maintainers. And around 32 patches were declined. Some of these patches were already submitted a few days before I could turn them in. And some patches were not fine to be so useful or so impactful to the maintainers and they decided not to accept those patches. So those from the part of this 32 that were declined. The other outcome of the project was the blogs. I created a website where I have published 14 different blogs and these are primarily the semantic patches that I was able to work with. There are a lot of semantic patches that did not report any issues. So I could not submit any patches for a lot of semantic patches. But yes, for those where I could find potential opportunities for improving the Linux kernel, I have added blogs for those. There's still a few that needs to be added, but yes, right now we can't stand that 14 blogs. I also was able to make some minor contributions to the kernel newbies wiki space as part of the internship. One of the task was to find such opportunities and keep improving the overall newbie wiki space. And also found opportunities where the coaxial scripts themselves could be improved. So I submitted three patches, which were in that improving the coaxial script itself for the betterment of it. Yeah, so at the end, what I achieved personally, I feel I have really understood the Linux code base very well. I have been able to successfully build and compile different drivers. This project was pretty horizontal. It was not aimed at one particular subsystem. The application was across the entire Linux code base. So I ended up compiling or building drivers for different architectures, different subsystems. And that really gave me a good understanding of the kernel code organization. I also learned how to use coaxial semantic patches for the Linux code itself, writing and editing semantic patches. And this is an ongoing learning, though it is a simple ASCII-based code that for semantic patches, you need to learn it. It's not very straightforward. So I continue to learn more about how to write semantic patches. But yeah, I mean, in my experience, once you write good semantic patches, they are very useful. And as you practice more, you really become efficient at it. So I'm expecting to continue my learning on this. I also understood how to work in Linux kernel, how to submit patches, learn how to interact with the amazing Linux community, very, very good and useful experience. And understanding the open source culture and communities overalls, this was one of the biggest learning. I was new to open source, so this participation really made things very clear to me. And also learn from the other mentors and the outreach support group about how I can utilize my experience and explore opportunities, create networks where I can utilize and try to get the paid job opportunities as well. Yeah, and the path forward, I'm now looking for identifying a subsystem or a driver module where I would like to build some expertise. As part of the current outreach chief cohort, I have been nominated as one of the mentors. So I'll be working on one subsystem and hopefully that is something that I will continue to build more expertise going forward. Secure necessary hardware and develop some testing skills. This one aspect that I could not achieve completely in those three months. So there are opportunities where I think I can develop some testing skills as well. I'll continue to contribute patches using the coxsignal script and also continue to learn about writing semantic patches. I wish to get closer to the community and as part of that, participating in the conferences and meeting the community members. That's something which I wish to continue to do. And yeah, I also want to explore and impact more in terms of the local community here in my town, my area and try to build a relationship with the Linux enthusiasts, try to develop more interest with the students who wish to work on open source or in the Linux kernel community. So I also intend to increase some participation in those areas. And as I mentioned, there are some blogs that I still need to write and complete. And also I'm looking for paid opportunities where I can build upon the experience that I've learned as part of my outreach intention. And finally about outreach, about my experience working with the outreach team. This has been the best team that I've ever worked with. I have some past experience working with different private companies. I work with different teams, but I think my personal experience working with the whole outreach group has been fabulous. I think this was the best team I ever worked with. The entire team is very understanding. They support you very well and they continuously encourage you through different challenges or obstacles that you might encounter. So they always drive you. Professionally managed, hassle-free payment. So this was one of the questions that I had initially, how I will get paid, et cetera. But I really don't have to work, don't have to worry at all about the payments or about how things will move. Everything was just moved as planned from day one. And they are very driving for success. Sometimes they realize somebody is slowing down and they kind of try to get in touch with that person. They really understand what are the problems, how they can help. So they're really driving interns to be successful in whatever project they are part of. It's a full open source mindset and community culture within the team. And they use modern tools and techniques. I've seen a lot of interactions using chats and a lot of modern tools are being used to monitor and track the application status, how the interns are doing, et cetera. So a lot of good things, tools are being used by the team. And they continue to promote skill development and they also keep tracking your progress throughout the internship program. So they are really very good at ensuring that the internships are successful. The interns are able to achieve their goals. And yeah, they really do a very good handholding. So I really find myself to be very, very blessed to be part of the Outreachy December course. And now I'm really looking forward to be playing that mentorship role in the upcoming Outreachy course. With that, I would like to thank and would like to know if you have any questions or anything that I can answer. Thanks, DeepVPAC, that was great. I guess I wanted to point out that your program, one of the particular challenges of what your project was that you had to work across all subsystems. There's two kinds of projects. And I think, you know, I was familiar with another one that had to work across many subsystems. And sometimes folks focus on one and they come with two different sets of challenges and you shared your patch acceptance rate. And that's a really great rate just for, you know, people watching, and that's a, you did a wonderful job with that. All right. Hi, I'm Jayhee. I worked on adding a new subnet filter, filtering feature in the kernel networking stack. And I had a great time working with my mentors, Ruka, Stefano, and Andy. So I wanted to point out three areas I found really valuable in developing within the Linux kernel. So the first is I worked mainly in the networking area. So I learned a lot about the internals of the networking stack. And I also learned a lot about debugging tools and building a workflow that's very efficient, like building a minimal image and testing tests very quickly. And I also learned to make a lot of great tests and had a wonderful opportunity to use a library for creating the self-test. So, and in this talk, I will focus on two topics noted by the arrows. I'll talk first about the small feature I added to the networking stack. And then I'll talk about creating self-test used to library. So I wanted to talk about some basic networking concepts before moving on to the project. So ARP is a communication protocol. And here in the yellow, you can see the Wireshark data that I took of the communication between my router and my computer. So it kind of goes like, my computer would say, who has IP address 191.6801? And then my router would say, yeah, that's me. And this is my MAC address. Who are you? Tell me your MAC address. And then my computer would say, yep, this is my IP address, 0.31, and this is my MAC address. So between the router and the device, it's using the ARP protocol to kind of relay the IP address and the MAC information. And GARP or Quartudas ARP is when a device announces itself without being prompted by an ARP request. So usually you're responding to a request, but in this case, you would just announce yourself without being prompted. And by default, the devices are configured to drop all of these Quartudas ARP frames, but you can enable the device to accept GARP with the ARP accept system control. And another thing to note is, sorry, I forgot to turn on my computer. Another thing to note is there's IPv4 and IPv6. So in IPv4, it's called ARP, but in IPv6, there's its end disk or neighbor discovery. And the GARP that I mentioned was is unsolicited neighbor advertising in IPv6. And this is controlled for enabling the different behaviors is ARP accept in IPv4 and in IPv6, ARP drop unsolicited NA or accept unsracted NA. So the goal was to provide a subnet filtering option for GARP during neighbor discovery for both IPv4 and IPv6. And the patches were sent to the net next tree of the Linux kernel, which is where all the networking development happens. So this is how it was implemented. A new option was added to the ARP accept system control. So in case two is where I added the new feature. So previously it was binary, it was accept gratuitous ARP or don't accept. But now I've added a third case, case two, where it would accept ARP or gratuitous ARP if it's in the same subnet as you. And this same feature was implemented in IPv6. So next I'm going to be talking about creating tests to validate the new feature that I've implemented. And creating tests is actually one of the first things I did starting the project to learn more about network topologies. So in my case, it was pretty simple. I'm setting up two namespaces and each has a interface. And then I'm creating a BE pair between the two interfaces. Then I use ARPing to test. So I had a great opportunity to use the library, that's the font I made with the help of other interns. And for just the setup test, this is just a setup process. You can see that on the left, it's much longer without using the library, but on the right with using the library, it's a lot cleaner and a lot shorter. So the library kind of extracts a lot of the common code from the test and eliminates repetitive code when setting up the network topologies. I'll delve into more detail of the code on the right. So for setting up namespaces A and B, it's as simple as calling NSAB. And then creating a BE pair between them is simple as BEA and B. So this is it. This is all you need to do to set up. And then you can also use functions like address get to get the IP address given the device interface. So yeah, that was a great experience learning to use the library, creating a lot of tests and implementing a feature within the men's kernel. I learned a ton. My mentors helped discuss various ideas and improved on multiple iterations of the patch sets. And previously I was, before I was really scared of the men's kernel community and working with my mentors gave me the confidence in interacting with the community. And I thought that the connections made in the open source community and with the mentors was especially incredibly valuable. Thank you. Yeah, you can check out my blog and my Twitter here. Thanks, Aureggie. Hello everyone. My name is Karna Stolarek. I'm a software engineer on I-915 driver team. That means that I'm mostly working on graphics drivers nowadays, but today I would like to talk about something different. That is my outreach project, which was to build a Memblock simulator. But before I start talking about the project itself, I think that would be good to explain what Memblock is and what do we mean by simulator in this context. So Memblock is a boot time memory allocator. It is a special mechanism that is used before the usual memory allocators are initialized, which is very early boot. And it has a broad variety of APIs where you can register or remove memory regions and also allocate physical and virtual memory. As for the simulator, it is just a user space program that runs the kernel Memblock code. And it can be run in user space thanks to mock definitions that I had to provide as a part of my project. And in addition to this, I wrote a series of unit tests that exercise basic features of the allocator, as well as allocator functions. So the name of the project was to create Memblock Simulator. And I had three main goals, which was to write a blog post about Memblock to learn its functionalities, how it works and what should be tested. And I had to provide a skeleton of the simulator, which was put to live in tools testing infrastructure with the requirements of reusing the actual Memblock code, identifying what kind of definitions I have to provide in order to even compile this code and provide a couple of test scenarios that verify that Memblock does what it's asked to do. And as a stretch goal, I was to experiment with different memory layouts in QML. Overall, I was able to do the first two. So here you can see my blog post about Memblock and I implemented a Memblock Simulator and provided most of the definitions that were required. But unfortunately I didn't have time to experiment with different memory layouts. So the main highlight here is that I was able to ship an initial version of the Memblocks test suite. I provided a lot of the stuff definitions that could be reused in other tools and projects. I implemented tests for basic API as well, thanks to the addition of simulated physical memory, I was able to test allocation functions that return virtual addresses. But it wasn't a smooth ride, especially because I was greeted with hundreds of compilation errors and I had to walk through each of them one by one to see what kind of definitions I have to provide in order to even compile Memblock code. But it went surprisingly well. I was able to get this done in a week and a half, I believe. So it wasn't that scary at all. And the second one may seem obvious right now, but it wasn't to me back then. So the allocation functions require valid memory addresses. And before that, I just picked just arbitrary addresses, which wasn't great. We wrote this later on. And there was a simple solution to that. I just had to malocate and chunk of memory and ask Memblock to work on it. So yeah, it will take a long, long time to get into and out of the project. So here I'm linking a couple of resources if you want to learn more. First of them being the official documentation. The second one being the blog post I wrote as a part of my outreach internship. And two of them are linking to the patch series that I sent as a part of my project with the first one introducing the basic tests and the other one and the tests for allocation functions. So yeah, so that's all. If you want to just ask me a question, don't be shy. Reach out to me. Here's my email and muscle handle. And thank you very much. Thanks, Carolina. And you notice Carolina's email address there. I was really happy to hear that when our outreach connection ended, she joined me and is now working at Intel. As she said, you're working on graphics drivers now. Yeah, yeah, in DRM. And that's, that's is great. So yeah, I'm not doing so much in memory management, but yeah, it's still great work. I can, you know, I'm working in open source, mainly upstream patches. And usually I'm writing tests for the graphics drivers, but also I send some comments to the DRM subsystem. It just takes some time to get into this, so. Well, it's wonderful that you stayed in the community. Yeah, great. Thank you very much. Okay, well, next we have Rebecca McKeever. And this was, this is special, but not uncommon that we'll have a project and it will come back for a second round as did Memblocks Simulator. So let's hear from Rebecca. I worked on extending Memblocks Simulator that was introduced by Carolina. I made many extensions and improvements to the simulator including API improvements, tests improvements, new tests and introducing NUMA support for NUMA layer memory layouts. So the first thing I did was added various testing outfits so you could see which Memblock test was being tested and also the name of the test and whether it passed. And I added labels to like top down and bottom up to for the verbose output for alloc test. Verbose was initially a build option, but then I changed it to runtime option. And I also changed movable node to runtime option and introduced a help menu. And I also added a build option to enable debugging messages and to enable NUMA support. I improved some of the Memblock alloc functions that are expected to clear a memory region. Previously the tests either didn't check or they checked the first byte. Now they prefilled the entire region with non-zero data before the test and then checked the entire region after the test. And I introduced new tests for several functions that were already being tested and introduced test coverage for several of the alloc functions as well as set bottom up, bottom up and trim memory for the Memblock alloc raw functions. They don't clear the memory region but they're otherwise the same as the corresponding functions. So instead of creating separate tests, I created flags so that you could test the raw versions with the same set of tests as the regular versions. And I had the raw versions checked that the entire region was still non-zero. And to add NUMA support, I set up a memory layout with multiple NUMA nodes and a previously allocated dummy physical memory. And I used eight nodes of varying size between 1 1 1 4th of the total allocated memory with NIDs from zero to seven. And then I had tests for Memblock alloc try NID and Memblock alloc try NID raw and Memblock alloc exact NID raw where the NID was set to from zero to seven. One of the challenges that I was not able to complete was adding tests trying to add or reserve the 129th region to trigger and unlock double array. I was able to write tests that succeeded at the task but then they caused other tests to fail. They were not restoring the memory regions properly. So outreach has been a great opportunity for me and I'm grateful for feedback and support I received from mentors in the open source community. And I feel more confident contributing to open source projects. And you can read more about my outreach work on the blog that's linked here. And Rebecca, you're at Collabora now? Yes. Yes, so Collabora is another frequent sponsor overall of the outreach program, meaning that they donate funds to the outreach program. So I'm Sabine, I was outreach intern last year. My mentors were Andy, Rupa and Stefano. I started my outreach journey by sending small cleanup patches during the contribution period. So these were small changes but they will improve the readability of the Linux kernel driver code in the staging area. Then I saw Stefano's call on improving the embuto script which stands for minimal builder using terse options. So embuto is an image builder for lightweight virtual machine environments. And one specific area that Stefano wanted to improve was running the kernel self-tests. I spent a week or so to understand Stefano's script and what was doing and what needs to be done. And this followed by lengthy chats with him and countless email exchanges with Stefano, which significantly helped me to improve my understanding of shell programming. So then I spent the remaining time of the contribution period by adding a feature to embuto that streamlined kernel development. So to understand the future, let's first consider the typical workflow of a kernel development inside the virtual machine. So the bugs do not affect the machine. So to this end. And then I wanted to interrupt. I'm not seeing in the slides progress and I looked at your slides. Okay, I'm here right now. Okay. So a kernel developer makes the code changes to the kernel inside the virtual machine. Then add self-tests or compiles and boot the modified kernel in the virtual machine. Run the self-test and ensures that they all pass. And this cycle is continuous. Last two steps are very tedious and take a lot of time. I think somebody is unmuted. So last two steps are tedious and take a lot of time and that's where embuto helps. So here embuto comes and embuto helps the developer to lighten these last two steps. So with embuto, the kernel developer can develop the code and add tests outside of the VM working on their own machine. After the changes are done, the developer can compile the kernel on the main host and run embuto using the command that I provided here. So as you can see, the output of embuto command is passed as an init-rd argument to KVM. And embuto creates an init-rd image that contains all the tests from the compiled code on the main machine and runs the net tests when booted, which is specified by dash C. So when a parameter, when a developer runs this KVM dash kernel command, KVM runs a virtual machine and boots the image that embuto created and then runs the self-test, which is much faster doing it manually. So what I did was my contribution was to, my contribution was like, to optimize embuto, to build images faster. By default, embuto was putting all the modules and all the tests into the image, which was taking around five minutes on my machine. But I improved the embuto so that when a user specifies a test collection, such as dash C net, embuto automatically finds the modules required to run, only these tests, and creates a much smaller image. With my contribution, embuto created an image in just 50 seconds on my machine. So after wrapping up with embuto, I checked other projects that I wanted to work. So I was particularly interested something that related C programming language. So I choose to fix a bug in VLAN bridge binding module without knowing what bridge binding is. So I spent lengthy time to read all the concepts like VLAN, bridging and other necessary networking concepts and did a code walkthrough with Andy. And Andy helped me to understand important parts of VLAN and bridging modules. Once I understood the networking concepts and how they mapped to the code structure, I tried to find the cows of the block. During our regular meetings, I learned from Rupa about the Perf tool and how we could insert dynamic trace points to the back kernel code. Rupa provided me with initial examples of how to use Perf props and explained how they work. So after working on VLAN bridge binding modules, I understand that it's really hard to find the bugs, but my mentors helped me a lot. And after finding a bug and finding solution, the very first step was to get my mentors approval. Then I sent the patches, but of course there were issues and the maintainers disagreed in certain parts. And I spent last a few weeks by sending and receiving the email exchanges with the mentors and also maintainers. Yeah, this was overall my experience. And right now I'm about to wrap up my degree and this outreach internship gave me enough courage that I am now applying Linux kernel developer positions and I heard back from Canonical and I have ongoing application process with them and wish me luck on that. And I want to thank you all my mentors and everybody else that made this possible, especially our 3G, thank you. Thank you, Savin, and yet you need to keep us informed about Canonical. That sounds wonderful. Sure, I will. Any final thoughts? I was wondering for all the interns, what was one of the most intimidating things that you faced while you were going through the program and a couple of you mentioned that you were braver or you were a little hesitant or scared to work with the Linux community. So does anybody have any like, wow, this was really hard or this maintainer was pretty difficult to work with but you got through it like experiences to share? Yeah, and this is deeper. So in my experience, I think what I realized working with various subsystems, there is no compromise in terms of quality. Everything that you submit has to be top notch and it has to meet the highest standards of quality, highest standards of performance. There is no acceptance to any, even a minor miss in your submission. So the perfection is definitely necessary in whatever you are doing and that's where sometimes you have to, you receive a lot of rejection or sometimes you receive a lot of feedback but at the end of the process, when you see your patch accepted and you look the difference where you started and what you ended up submitting, you can clearly see the best coming out of you. So I think it has been my experience that you need some time to really understand why sometimes the feedback is hard but at the end of it, when you see what you have been able to achieve because of that hard or that feedback, you really feel great about realizing a new dimension about yourself. So I really feel initially it was not that easy to work through so much of the feedback but yeah, once you start understanding you get used to it and eventually nowadays if you don't receive feedback, I feel like somebody is not looking at my patches. So you now get used to knowing more from your mentors, knowing more from experts and you really feel like they should comment on your code. It becomes a habit. So yeah, eventually you get there. Thanks. I'm not sure I answered your question there. No, no, that was a great response. I'll let David, it looks like David wants to say something. Right, so looking back, we had a lot of projects in the kernel that are more focused on, it's a simulator, testing, self-test, these kinds of things. Of course, like whenever we're dealing with such projects it's fairly nice for a mentees because usually you're working on a very like small subset of the Linux kernel and you're not as exposed to, let's say, feedback from some other folks that might respond in certain manners to your patches. But looking back, would you, meaning US mentees have rather enjoyed working on something that is like part of the production kernel, meaning not like some testing or simulator but like some actual feature or cleanups in the kernel or did you actually enjoy working on that fine subset in a low-controlled environment? That would be my question. I really like the idea of working on a self-contained project especially there was something that I could just show and hey, this is fine or I started this and then people started working on this and using it. So it was very rewarding for me. But yeah, I mean, this is really nice that you are limited just to one thing because a kernel is huge and before joining Outreachy, I wasn't even aware that there are many subsystems and they don't really talk to each other. So yeah, so I really like my internship and the way how it was organized. Very good, yeah. I mean, I've been working for years on the kernel and I still think I've only seen a small subset. So yeah, I guess you never can run that. Yeah. I think the self-contained part is important for the internships because it's only three months and like you guys have been talking about getting your patches reviewed, three months is not a long time. I don't get a lot of stuff up in three months. So we want you to have a result that's meaningful. So we appreciate when mentors can subdivide and define something in a small enough box that you can make progress. Yeah, I have to give a lot of credits to my mentors because they provided a lot of guidance or like project idea that was well-formulated enough that I could really go and tackle it. I think it was already really fleshed out and very a lot easier for me to follow and get it to production or get it to final code. But also after that, I think after that well-defined project, there was also an opportunity to work on like some newer things that I haven't worked with, like FCP in my case. I don't have it in my presentation but I thought that was really interesting to like delve into different areas and learn more. And that hasn't been like formally submitted upstream or anything but it was still a great opportunity to learn. So just a combination of that was great. Well, thank you everybody for joining in and you'll see this, I'm sure you'll participate virtually at least in the OSS Summit on May 10th and onward and you'll see yourselves there. Thank you. Thanks, Alison.