 Welcome to the Outreachy Kernel Internship Report. I am Alison Schofield, the current Linux Kernel Community Coordinator, and I will be introducing you to our most recent cohort, Beatriz, Deborah, Metali, Samera, and Janzea, who've all recently completed Outreachy Internships. Outreachy, this goal is to increase diversity in open source. Anyone who's facing under-representation, systemic bias, discrimination in the industry is invited to apply. These interns get to work with experienced mentors in many free and open-source software communities. I believe at last I peaked over 100 different FOSS communities have participated in Outreachy. These internships are paid. The interns receive a $6,000 stipend. These internships are remote. Both the interns and mentors work remotely. They've always been remote, just like for the Linux Kernel World. Much of our work is done with people across the globe that we only see on mailing lists and now in a lot of Zoom meetings. These internships last for three months and do require a full-time commitment. They're offered twice per year, May to August, December to March. For FOSS communities, like the Linux Kernel Community, coordinators sign up their communities in each round. Mentors submit projects under our community and community coordinators approve the projects. That's the state we're in today. As I record this video, we are seeking out mentors for Linux Kernel projects. For the interns, they fill out an initial application where they check to make sure that they meet the eligibility criteria. Then they go ahead and make contributions to FOSS communities according to that community's guidelines and they submit a final application to a community and project. Here's a little more on the timeline. This is the round that we're in right now. The initial application deadline has passed. The project list is not yet finalized. Once that is finalized, the contribution period will begin. Aside from the internship itself, it's like the most busiest and the most exciting time of the whole process. After that contribution period, interns submit a final application to the project they want. Interns are announced and their internship period begins. This timeline repeats. So we do this whole thing twice a year. So that kernel contribution period, for 30 days, the applicants, the mentors, and all group of additional patch reviewers are in close collaboration, supporting these interns and helping them through the application process. They join a special mailing list. They complete a first patch tutorial and they submit their first patch to the Linux kernel. This is a thing to be celebrated. If you go no further, they get in your first submit accepted. Did I say submitted? Accepted in the Linux kernel. That's something to celebrate. You will see the interns all in their blogs and their social media celebrating the day they got their first patch accepted. Once they get past that, they start working with mentors to do some small project-specific tasks to see if they can find a project that would be suitable for them. Finally, they'll record their contributions and submit a final application. So the Linux kernel has a long history in outreach. We've been in it since 2013. More than 55 interns and mentors have been in this program. There have been six community coordinators so far. I'm number sixth. I'd like to mention the prior five, Sage Sharp, who started this whole thing, Julia LeWall, who continues to be super active on the mailing list and a mentor in the program, Vashali Thacker, Shadra Bark, Helen Coyke. Vashali and Helen were just doing it this past round and have decided to pass the torch on to me. Now Vashali, Shadra, Helen and I are in a special club. We are also outreach alumni. All of us were originally outreach interns and some of us then were outreach mentors and then outreach coordinators. So as you can see, once you get hooked in this program, you keep participating. And it's not just us organizers. There's a whole additional group of volunteers that make outreach happen. Former mentors, other Linux kernel maintainers and developers all pitch in during that contribution period to make the program a success. So what do the interns do? Well, they contribute across the board in the Linux kernel. Famenta can define a project with a scope that is good for an intern. It can come into Outreachy and he has a laundry list of all the things that the interns have done. And additionally, it's interesting to note that the Outreachy group has been a top contributor to the Linux kernel for pretty much every kernel release when the numbers are published, the volunteers of Outreachy. A lot of it is due to what happens in that contribution period. They do so many cleanup patches across throughout the stage and drive is that they end up being a top contributor to the Linux kernel. So this cohort today and they are they've done an amazing job. Here is their list of projects. Again, there's drivers and there's the course scheduler. These are not simple projects. Excited for you to listen to their presentations. And this presentation has been given once or twice a year. We bring out the interns and they present their projects. And every time there's somebody in the audience who says, wow, I didn't know that they did that much. They're always super impressed. So I'm looking forward to you being impressed right now. Let's get it started and we'll have Beatrice tell you about her internship first. Hello, my name is Beatrice Carvalho and I'm here on the Outreach kernel internship report to show you about my internship on the project, improvement on the kernel GPU subsystem. My mentors was Melissa Wendt and Daniel Vether. I'm from Brazil, but I've been living in Portugal for almost two years. I'm a computer engineer with emphasis on the embedded systems. Of course, my interest are is the Linux kernel. When I start my internship, my object was create new future and better understand how the DRM car works. To achieve this objective, I choose two tasks. Clean up the debug.fs support and remove custom dump map of set implementations. After deciding the two tasks, the internship goals was use the coccinelli to filter functions, refactor the code, run the new code with vkms and learn how to work with the Linux community. Very ambitious, right? But the plans changed sometimes. So what I did? During the event of the first task, we found that it couldn't be carried out as intended. So it needed to be restructured and change what I would do. Results in created the function vkms config show to which I meant to print the data in DRM, the debug.fs create files. And during the development of these functions, I came across an improvement in the code where I replace a macro in a vkms release. Both activities had arrived being reviewed and I proved to be part of the DRM MISC tree. In the middle checkpoint was realized that I was not going to be able to do the second task, because it is in another context and could take a long time to me understand how it works and how to solve it. So we drop off. I continue working in the vkms config debug, try converted into a struct proposed by Ambui Quaruga. It was a privilege in turn in the project. But when I realized the internship they derived and they could finish this activity, I learned a lot of things during my internship. How to use the git, how to build the kernel, how development kernel cycle works. But I think the most important where Linux kernel development is not linear. Several things can happen. We can have setup problems a lot of times. Sometimes we're broken the kernel and sometimes not knowing what to do. So when this happens, it's very very important you take a deep breath and step back to solve what happened and what I need to do to fix it. Other things that I learned is the outreach goal is learning how to contribute in the open source and how I can work with the project chose. The experience that I will have with my internship on the Linux kernel was amazing beyond that I imagined. Because I feel support and encouraged to explore the Linux kernel, how the development cycle works and I was encouraged to ask help both with my mentors and the community and how it works with the community. Because of this I learned a lot of things like the importance of communication. That it's very important to be clear about what I work, explain why I do the modification or what I would improve with this modification for example. And during this time I learned to have more self-confidence in what I do and what I was working. And I started back to enjoy programming. I know it's crazy but it's true. And because this I think the most important is I want to continue working and contributing to the Linux kernel. So in I would like to say thank you to thanks to Outreach Program to this opportunity for working with Linux kernel and thanks to my mentors Melissa and Daniel for taking your time teaching. Please feel free follow me in my blog OpenSorceries where I post about my outreach internship and I will continue post about my discovery about Linux kernel work and other things. So thank you very much for your attention. Have a good day. My name is Deborah Brower. I was an Outreachy intern from May to August of 2021. The name of my project was improving the HDMI CEC compliance test and the CEC emulation of the Vivid Driver. My mentors were Hans Verkau and Johan Fieldsvecht. About me I live in Victoria British Columbia Canada and I study computer science at Thompson Rivers University. So to understand my project you need to understand what is CEC. It stands for Consumer Electronics Control and it allows devices that are connected by HDMI to communicate with each other. It's mainly used in home theater systems. So on my slide there is an example. We have a TV that's in standby mode. It's connected by an HDMI cable to a playback device. A playback device is just anything that plays content to the TV like a DVD player or a streaming device like a Chromecast. When you press play on the playback device it can send a CEC message through the cable to the TV to wake it up first before it starts playing. So CEC is a convenience. It saves you from having to separately wake up the TV when to press play on your playback device. It can be a lot more complicated than what I've shown on my slide. There can be up to 15 connected devices all talking to each other and they can include TV, multiple playback devices, audio systems, tuners and recording devices. So the first part of my internship was focused on CEC compliance tests. CEC is a protocol and it's part of the HDMI specifications. So devices that use CEC have to follow the protocol rules so that everyone is speaking the same language and their behavior is predictable. So compliance test would check that a device is following those rules. So here's an example on the slide. Say your TV is playing and you press pause on the TV remote control. The TV could send the pause message to the playback device. The playback device would pause the media and then the playback device is required to send a status update back to the TV to let it know that it successfully paused. If the playback device doesn't send that status message back then the playback device is not compliant with the CEC protocol and the compliance test would check that. The compliance tests are in the video for Linux utilities and I focused on three of them specifically. Deck control, one touch record and timer programming. The second part of my internship focused on the Vivid Driver. The Vivid Driver is a test driver. It emulates real hardware devices so that application developers can test their applications without having to own all the specialized hardware in which their application might run. Vivid emulates CEC devices and it had a bug in it where occasionally it would lose messages. So on my slide is an example of how this would happen. The TV is sending a get info message at the same time that the playback device is sending a play message. You can't have simultaneous messages transferring in both directions so the TV gets priority and the playback device has to back off. The playback device will try again but on my slide the TV continues to send get info messages and after four times the playback device will just give up and the message is lost. So that was the bug. Our first attempt to solve the problem used an existing internal kernel API called the CEC PIN framework. The PIN framework is used by really rudimentary CEC hardware that just controls the CEC PIN on the HDMI connector but we found that it required PIN level timings that were too sensitive to emulate. If we had timer overruns greater than 0.3 milliseconds messages would still be lost. The successful solution was a whole new algorithm that re-implemented the CEC bus. It used message level timings so the timer requirements were not as sensitive and it also used signal free time requirements which basically forced the devices to take turn sending messages and to share the line better. So what did I learn during my internship? I learned how to write code with the help of other people. So I learned what is a code review and what's it like to get feedback and to iteratively change and improve your code based on that feedback. I learned how to approach a really large code base, how to use tools like Git and the virtual machine and the GDB debugger, how to read and interpret HDMI specifications, how to write a compliance test, what a kernel driver looks like, how it's organized, and how to use kernel functions like locks and timers and threads and how to do kernel debugging. So that's it for me. I want to especially thank my mentors, Hans and Johan for so generously sharing their time and expertise with me. Thank you to the outreach organizers for this amazing program and thank you for watching my presentation. Hello everyone, I'm Natali Bulkar and I'm here to present my project of Outreach and Linux kernel internship. My project was to create a scheduler test suite to understand functionality and performance of core scheduling. My mentor was Vinith Pillai. About me, I'm an engineering student at IIT Roorkee, India. I'm also an outreach's summer return with Linux kernel. Talking about my project, let's first discuss about a core-scaled feature. Core scheduling aims at making hyperthreading safer from hardware vulnerabilities like speculative execution attacks. SMT, that is simultaneous multi-threading when enabled, helps running multiple tasks at same time while maintaining computer performance. It virtually doubles the core that are on CPU. It groups trusted tasks on a core. It treats the CPUs in SMT core as a unit, finding the highest priority task on all CPUs. That task will drive the scheduling decisions. If another task is found that is compatible with high-priority task, it will be able to run on a sibling CPU. Otherwise, that sibling will have to be forced idle. Coming onto my internship goals, my task was to write a comprehensive test suite to simulate scheduler workloads. Then to collect traces, compare the performance results, the baseline in SMT off, and to reiterate on the test suite to add more capabilities. The main point was to analyze the puff traces and detect if the feature is working as expected. That is, no trusted tasks get to share a core. As I move forward through my internship, goals were revised. It was to create a case self-test to check and compare the performance with SMT enabled, SMT enabled with core scheduling, and SMT disabled. What I did was, I created a self-test that ran two threads on a core. One thread is a CPU stressor, and another one is a memory stressor. This test has five variants. First, both threads run without cookie. The next was to run one thread with cookie, and other without cookie, and vice versa. Fourth one was to run both threads with separate cookie, and in the last variant, one sibling is turned off, and tests are run on just online sibling of core without cookie. Each mentioned variant runs for a few seconds. In my case, I ran for five seconds. I checked which test was performing worse than hyper thread off test case. Future work. Coming on to future work, in upcoming time, I am going to build on this small test case and come up with full-fledged test suite to generalize the current Python course kit script by Julian, which works best for virtual machines to be able to work on all operating system. Throughout this internship, I learned a lot of things. I learned about Linux kernel development. I learned how to write kernel code, what is API, and how to use it in the code. I learned about few tools and commands like gdb and perf. Talking about perf, it is very powerful. It can instrument CPU performance counters, trace points, k-probes, u-probes. It is also included in Linux kernel under tools slash perf. I learned how to work with other people on the same task, and to ask questions when you are stuck. Communicating with people and community really helps. At last, I am grateful to my mentor, Vinit Pillai, for being patient, teaching me and guiding me throughout the internship. And thanks to Outreachy for this amazing opportunity. It was overall a great experience. These are some resources which I use during this internship. Thank you so much everyone for your attention. Thank you. Without requiring hardware support, this is great for running tests or eggs on machines where we don't have hardware support, but we still want to check the robustness of our code, like within a CI. My project mainly comprised two code areas. One of them was the weakness driver, which is part of the GPU driver system. The other part was Intel GPU tools test suite, which is a collection of tools for development and testing of the DRM driver from user space. The initial goals for my internship were in two parts. One of them was to expose the VKMS driver through the configFS file system. The other was to introduce V-Planckless or virtual hardware mode. Now configFS is a file system that enables creating, managing and destroying kernel objects from user space. And it is very useful when you want to say test or run multiple instances of a single driver. About the VKMS, about virtual hardware mode. Now VKMS tries to mimic actual hardware by mimicking the interrupts that are found in graphics hardware, which are called vertical blanking interrupt. We wanted to introduce a feature where it can also emulate virtual hardware, that is how we use virtual machines in KMU or by KVM. So this would mean a feature where we can have a KMS driver without vertical blanking interrupts or a V-Planckless mode. However, a month into the internship we realized that our initial goals are not very feasible. Given the amount of time we have, so we decided to only focus on implementing V-Planckless mode and preserving the tests except the tests which depend on V-Planckless interrupts directly. I initially thought that the implementation would be as simple as checking if virtual hardware mode is enabled and then disabling the V-Planckless interrupts and cleaning up the code a bit and that would be it. That was not to be. When we disabled the V-Planckless interrupts, all the tests failed. This obviously happened because the tests were not written in mind, written keeping in mind that we might have code where we need to skip V-Planckless interrupts. So we had to modify the tests a bit wherein the tests check if V-Planckless interrupts are enabled. If they are not, then all the tests that require V-Planckless interrupts or specifically check operations related to V-Planckless interrupts are skipped. Well, all the tests passed. I thought that would be it. But turns out, even for the tests that passed, there were some demessage of errors. I realized this is the cause. It is not necessary that before and after my patch, the tests are passing the same way. Definitely the code has changed and there might be some errors under the hood which are not affecting our tests, which our tests are not looking for, but there are errors that can cause crashes still. So there were two errors. One was memory allocation problem. We solved that by using virtual Manok, which allocates memory over a few pages. Instead of looking for a contiguous physical memory, the other error we were facing was a flaky V-map allocation error, which was already present in the VKMS driver. But it was interacting with my patch to produce a kernel panic. Thankfully, around this time, the part of the code that was where the error was happening, it was changed a bit in an unrelated patch by Thomas Zimmerman, which solved it. So good to go, right? No. There was tests that were still failing. So tests that were based on CRC, which checks for data loss in the frames that are being sent to the screen, were failing. This was because CRC is currently implemented around the vertical blanking interrupts. So we need to refactor a lot of code and refactor a lot of tests also and implement CRC as a one-shot operation. Since this would require a significant amount of testing and refactoring, we decided that at least for the first patch introducing virtual hardware mode, we can just skip all CRC tests and operations. And well, after this, my patch is something that we are mostly very happy with. So Avicii taught me a lot. During my code review and the process of iterating over patches, I learned a few things, which are checking the message logs, even if test results are preserved, because maybe under the hood, things are working differently. And it's important to keep an eye on them. Also that every time we change code, we should check for new race conditions. And maybe sometimes there are no more race conditions that might happen because of the changing code. So we also need to be careful to remove the logs around this part, where we are relatively sure the race conditions might not happen. I also learned how to use the atomic interface, which is used extensively in the DRM subsystem. And the patch review process also helped me write a cleaner code, which also becomes very easy to test later on. I also learned idiomatic C, island, tumors like f-trace can communicate. And a few general things about software, how it can be very tough and very rewarding. Also, planning ahead is very important. And having a great speed or where you can catch up in case something goes wrong is also necessary. Working as part of an inclusive community makes a lot of difference in terms of motivation and quality of work. And it also helped me overcome my imposter syndrome to ask questions in open forums. I'm very grateful to the DRM subsystem for being such a wonderful community to be part of. In the first part of my internship, I did, I saw some low-hanging issues, which really helped me get acquainted with the system. Here are the links to them. I plan to continue working on the weekend as a driver. And this is what I've thought for my future work. Lastly, I would like to say that I'm very, very thankful to my mentors, Daniel and Melissa, who were so patient and allowed me the time to make mistakes and grow and taught me so much about software. And a huge thanks to Sage and Veshawani and Helen. And all my fellow interns for making our produce such a wonderful experience and great community to be part of. Earlier, I used to think that I would use majorly about building software and best practices. I realized it's more about building a software community, which is a diverse, inclusive, welcoming and a wonderful safe space to be part of. That's all from me. And I would like to thank you. Hi, my name is Sia Bagdolet-Kaze. And today, I would like to talk about my internship at Outreachive. This summer, I was an intern for Linux Kernel under supervision of my mentors, Pival's Attachion and Tyler Hicks. The main objective of this internship was to introduce kernel self-test for kernel same-page merging feature or KSM. The kernel self-tests are a set of small tests that exercise individual code paths in the kernel. What is KSM? KSM is a memory-saving feature, which makes use of duplicated pages. It merges only private and anonymous pages and can be enabled by using M-Advice's code. Since virtual machines contain a lot of pages with the same data, KSM was initially intended for virtual machines. But now, any applications that generate many instances of the same data can use KSM. KSM performance can be tracked by using its C-spiles, where you can find information such as the number of shared pages or sharing pages. I started off by writing some unit tests. Unit tests are used to independently test the functionality of server modules. I implemented several unit tests for KSM during this internship. The first test validates that with different tunables, the right number of pages are merged. Along with that, we must also check that no longer duplicated pages must be automatically unmerced by KSM. Also, KSM treats differently zero pages. It depends on user pages' tunable, so it can either merge with the special kernel zero page or treat them as other usual duplicated pages. And finally, the last test validates that KSM is properly handling pages in different numeralodes. So, for instance, if there are two identical pages in two different numeralodes, they can be either isolated from each other or be merged. After unit tests, I implemented some performance tests. These tests are a little different than unit ones, since performance tests are mostly intended for developers when they are making some changes to MM subsystem to see if their changes are somehow affecting the performance of KSM. And there are two key points in performance tests. The first one is, of course, merging speeds. The first test provides merging speeds of duplicated pages in megabytes per second. And the second test evaluates latency of copian write breaks. When we want to modify already merged pages, these pages must be copied again so we can write on them. So this process of copying adds some overhead. As a result, this test provides two numbers, one for write access speed for unshared pages, and the second one is write access speed for KSM merged pages. During this internship, I learned certainly a lot about journal development overall structure and its cycle. For example, difference between RC trees and Linux Next Tree and how different subsystems are maintained. Also, since it is open source, it is not enough to write just a piece of code. You have to conform to the established style of communication. And I learned a lot about the structure of patches and how to properly send them. In addition, I gained very in-depth knowledge about the memory management subsystem, about its overall structure and code base, and etc. And finally, I had some experience with Git, but thanks to this internship I was able to practice it on a more complex and big project. And also, I used virtual machines for the first time. I mainly used them for testing my newly compiled journal. I would like to thank all the outreach organizers and especially my mentors for letting me gain a lot of knowledge throughout this summer. And that's it from me. Thank you for your attention and listening. Bye. Thank you interns. So I hope you were amazed, impressed, and if you want to find out more about these interns or find out how you can help out. I have some contact information here. Companies or individuals can donate. We always need Linux kernel developers to volunteer as mentors and help review patches. Let me pause and give one final thank you to the mentors behind all these interns. I believe each one mentioned their mentors. Pavel, Tyler, Melissa, Daniel, Vanith, Hans, and Johan, these were the key mentors that made the internships possible this round. Please outreach about the program in your professional circle, your local communities. And again, if you want to find out more about any of these interns, mentors, coordinators, look on the outreach.org website. Thank you.