 Hello everybody, welcome to this Outreach Linux Karen internship report. My name is Ellen Koike, I am a Linux Karen developer and also outreach alumni and also outreach co-coordinator for the Linux Karen project together with Vaishali who is the coordinator. I'm going to start with a quick presentation about the outreach program then we're going to move to the presentations from interns with Brian Osler, Jules Inge, Kaira Gupta, Burdres Pedrajas and Shriha Patel. Outreach is a remote paid internship to work with free and open source software. Interns get $5,500 a stipend plus $500 for traveling going to conferences. This year due to the pandemic was a bit different so organizers decided to pay the $500 anyway to help interns. The internship lasts for three months and interns are paired with mentors from the false communities. The program is organized by the Software Freedom Conservancy. It was previously the outreach program for women which was organized by NOM. We have two rounds per year so one in May and another one in December and the internships are financed by industry sponsors or false organizations. Who is eligible? So women, cis and trans, trans men and gender-cured people. US residents and nationals who are Blacks, African American, Hispanic, Latin, Latin, American Indian, Alaska Native, Native Hawaiian or Pacific Islander. Basically it is anyone who faces systematic bias or discrimination in the technology industry of their country and interns must be able to work full-time during the internship. So how does it work? The application process for applicants is the following so applicants must fill out an initial application for eligibility check, then eligible applicants make contributions and then they submit final application for the project. The application process for the false community is the following so coordinators sign up their community in each round then may enter submit a project under a community and the community coordinators approve the project. So this is a generic timeline just to give you an idea. So for the December internship the initial application deadline was in September 29th. We are now in the contribution period until the end of this month and the internship is going to start on 1st of December until 1st of March. The Linus Karnoff project has been participating in outreach since round six in 2013. Sage Sharpe was the first coordinator then Julia Lowell then Vaishali with Shadra and now Vaishali and me. We had a total of 50 interns and about 40 different mentors in a very diverse kind of project from several device drivers, three wide changes and other high-impact projects. During the contribution period we required interns to join the outreach Linus Karnoff main list to go through the first patch tutorial, do some cleanup in staging drivers to learn about patch structure, coding style and tools, then move to specific project tasks, start communicating with mentors and start doing the proposal to the list from the mentors. Then they record all the contributions on the Outreach's website and submit the final application. From the past two rounds, so just to give an idea, in December 2019 we had nine candidates with five slots, with projects from Spinlock, DRM, Esparas to NPS Store and last round in May this year we had 11 candidates for four slots from in networking, sound open firmer project and Linux media. We are now in the contribution period of our next round in December this year. We have four internships, four slots open with six mentors for changing internal API, scheduler, DRM, Moody Media and SPI. How can you help? So companies and individuals can donate funds to support interns. Linus Karn developers can volunteer as mentors and help reviewing patches and you can also outreach about the program in your professional circle and local communities. Here is contact information, so if you want to contact organizer you can send an email to organizers at outreach.org or if you want to talk to Vaishali or me feel free to send an email and you can also join the main list to help reviewing patches from applicants, from candidates. Now let's move to the presentation from the interns. So we have Brianna Osler presenting about improve and extend kernel networking self-test running in namespaces. We have Julis Airenge with fixed lock-related warnings reported by SPARS, four core kernel code, Kaira Gupta, Linux media and Liby camera, moodstream test support with Vink, Lourdes Pedrachas, improve and extend kernel networking self-test running in namespaces and Shria Patel, add SOF fuzzer support for IMX8 platform. Thank you. Hi, my name is Brianna Osler and I am here on the Outreachy Internship panel to discuss my summer kernel internship with mentors Deve Kharavi and Stefano Rivio. My internship project was titled improve and extend kernel networking self-test running in namespaces. In particular, the internship focused on TDC, the three-letter acronym for a testing suite of the Linux traffic control system. TDC is a unit testing suite implemented in Python. A little more about the internship. The goals of the project were to add TDC to kernel self-test in order to broaden its user adoption, promote its addition to kernel testing suites and catch regressions to traffic control more quickly. To add tests of the Berkeley packet filter or BPF classifier and to highlight TDC's scabby plugin by adding a test making use of its functionality. Lessons learned. I learned technical information, how to use certain tools and workflow with the community. Technical concepts I learned about were BPF. BPF allows analysis and filtering of network traffic. Filters that work in traffic control should be able to be replicated in BPF so I was to test and add and delete of a filter. We selected filtering on MAC addresses which involves writing a user space program to provide a list of whitelisted MACs which then get pinned in a mask to the file system for a BPF program to pick up and check against when it receives an incoming packet. TDC had this pre-existing scabby plugin and I used that to generate packets and pass them through the TDC filter. That work is actually still being completed on my end. More about that later. In order to learn about this I made extensive use of the kernel header files for BPF, read kernel code, man pages, and had lengthy discussions with my mentor to get to the current state. Tools that I worked with during the internship were MAC, Git, Git Bifects, C, Python, scabby, and BPF. The workflow. My work went upstream to the net dev community. I submitted code to Netnext and the IP Route 2 package. IP Route 2 contained the user space implementation of traffic control which can be run with the command tc while kernel slide changes went to Netnext current state. TDC has been added to kernel self-test in Netnext. Of the goals I've listed here that's the one that's been completed and achieved. I also did fix a few bugs that arose during regression throughout the course of the summer using Git Bifect and proposing fixes. My mentor David is looking into effects of the addition of TDC to case self-test on kernel ring and into better understanding adoption of TDC in current time. I do hope to get the work filtering MAC addresses out to the community here in the next month. My timeline has been somewhat slower than I had hoped for. However, I do have a working basic case that I am extending to add that MAC filtering to. I will say that actually working with that scabby plug-in was a lot easier than I thought so I'm pretty proud of that. Moving forward to talk about the experience. I did enjoy the experience of working with outreach this summer. I found the kernel community and the outreach community both to be quite helpful and friendly. IP route 2 and NetDev were both really friendly and welcoming to me as a newcomer. It was really a great experience getting to work with everybody this summer. I also learned a lot quite quickly and I'm really proud of that accomplishment. Before the start of the internship namespace, kernel self-test, traffic control, the difference between user space, kernel space, and scabby or packet generation were all new terms or ideas that I needed to learn about. In the internship application round I worked a little with a net test in kernel self-test and that was my first introduction to kernel self-test. So I really did pick up a lot during this time. I'm actually entering my third year of my computer science curriculum right now and I'm currently taking an operating system class. So it's interesting to me to see that same information presented in a different format right now. I'm very grateful to the community and to everybody who helped me during this internship and to everyone who is attending this panel today. Thank you for listening to my presentation. Welcome everyone to the outreach panel. My name is Jules Irenge. I am a PhD student. My mentor was Bokun Feng. My internship was titled Fixed Lock Related Warning reported by SPARS in the Linux kernel. In this Linux kernel internship I worked with SPARS which is a static checker for kernel code developed by kernel engineers. SPARS was originally initiated by Linux Torval himself. So to run SPARS in the Linux kernel code we run the command makec is equal to two in your directory. When you run for the first time you do makec is equal to two. For the second time when you have changed the file it is advisable to run makec is equal to one which only compiles the file that you have just changed and check if the issuer you are working on has been solved. A typical SPARS lock related warning in any file look like this. For example in a subsystem for this example I took a RCU subsystem but it can be any subsystem. We can find like warning like context imbalance so this lock warning only means that there can be a real bug here or there can be a missing annotation. Programmers can be sloppy sometimes and forget to write annotation for their codes or we might be in a situation where we have just its SPARS limit. My internship task was to go through all lock related warning in the call Linux kernel and fix the warning one by one accordingly. By fixing the by fixing I mean most of the time I added a missing annotation adding but we can add annotation like acquires. Annotation acquires only is added when the specified lock is held on function exit but not on function entry. We can also add must holds annotation when the specified lock is held on function entry and on function exit so held on entry held on exit. We can finally add a release annotation when the lock is held on function entry but not on function exits. We can also clear the warning by refactoring the code structure especially when annotation cannot fix the issue. This is a typical patch of mine a sample one it was a cleanup of 30 warning and someone in the mailing list sent me a note after reviewing saying that he was wondering whether this is a tree of mine or I'm applying this patch to my tree. I found it personally I found it quite a bit funny because I'm still in I was a kernel newbie I'm still a kernel newbie but he's talking about a kernel newbie having a tree that was funny to me. The returns are I got working I got experience exposure to the linux channel got experience working within the linux channel community I interacted with people in the mailing list I improved my understanding of the linux channel and also found a new passion I'm currently doing phd with verification of bpf subsystem. I found it quite interesting my huge thanks go to the outreach community and sponsors for making this opportunity available thanks to my mentor Bokun Feng for his guidance patience support and encouragement I would like to thank the linux channel community I had a great experience in the mailing list thank you for listening to me hello my name is Kairah Gupta and I am a junior at IIT Roorkee India I'm doing my engineering from there and I was someone I'll teach you in turn with lip camera I'm in the next kernel my mentor was Kieran Binkham let us first discuss what is whimsy so the virtual media controller driver or whimsy is used to emulate complex video hardware for testing purposes it uses the media api and reworld to be api for animulating the hardware it has a hard-coded topology which looks like this in the whimsy core which can be changed and the driver we compiled to suit the user's need it does have a look at the major problem we intend to solve during the internship so lip camera which is an open source camera stack gives support for multiple streams and it has a pipeline handler for whimsy which can be used to perform tests on lip camera but whimsy does not support multiple streams hence lip camera's multiple stream ability could not be tested on whimsy so let's see what I did the solution was divided into two paths first the multiple stream support in whimsy and second the multiple stream support in the pipeline handler of whimsy in lip camera so I first implemented multiple stream support in the pipeline handler of whimsy in lip camera using a path set by the class which allows multiple captures to attach for the single sensor so the scalar in whimsy by default triples the dimensions this can be changed using the controls but the default is three times so in case of ambiguous user impulse such as raw given 30 by 30 and RGB given 50 by 15 we prioritized the raw configurations and adjusted RGB accordingly then Nikolaus path set couldn't be used to allow whimsy to multiple stream as the path set created as many threads as the number of streams requested while in the case of multiple streams we need the frame to follow just one path by E just one thread so we decided this design for the streamer and implemented it whenever an enabling signal is sent to the start stream of the streamer it starts the stream it starts the individual stream and then it checks if a thread is present or not if it is then it unlocks the muting and if it isn't it initializes the pipeline the pipeline and then it starts the thread i.e the thread is started just one and the pipeline is initialized just one similarly if a signal for disabling is sent to a stream it stops the individual stream then it checks if all the streams have been stopped using the KRF if no then it unlocks the mutics and if yes it terminates the pipeline and it stops the thread so let's discuss the current status of this work the path set is still under consideration on the meaning list and the width pipeline which is a common object for all the streams is a common array of all the entities in the graph i have implemented it currently like this and it means improvements weren't it currently was first let's see what happens if i bit first search the graph starting from the RGB capture mode it gives the sensor in the middle well if i start the searching from raw capture sensor comes at one end while the captures come at the other end this width pipeline array is very important because it is what tells the thread the order in which the stream should be passed hence it needs to be in the correct order which is which in this case is the second order so in my implementation i check if it is the RGB which tries to initialize the pipeline if it is i go to the next entity which is capture and then i make it the know and start the searching from raw and if it is raw then there is no problem the search goes as well so this currently needs certain improvements certain optimization which is one of my future goals then i would try to get the entire path set merged i also have to change the pipeline handle of lip camda as several changes have been introduced in lip camera and pipeline handler ever since so i have to reuse it on the top let's discuss some of my other contributions as well so on the kernel side earlier mc did not show the order of expected colors over test image so a small colors which like blue in place of red or red in place of blue it's unnoticed at times which actually happen so hence i added a control which shows the expected color order description over the test image i on the lip camera side i added a stream parsing for pixel format in cam and q cam arguments earlier we had to give the hex values of the pixel formats in the argument for cam and q cam and now we just have to give their name similarly i modified the two stream helper in the camera for pixel formats b4l to pixel formats as well as for embers to give the pixel format names the 4cp values and the amber strings respectively so this makes it very much easier to understand the log and find the errors so all in all it was a very interesting experience and i enjoyed it a lot thank you there are several test screens created with the intention of testing the code of red however currently there is no standard to create common tasks such as the configuration of the space of the red name tunneled by the resultation of each other with which the logic is re-implemented of different sperms in addition to a test repeating the work carried out by other programs in addition when you need to add new tests take care of the creation and configuration of the 3rd row of a virtual test to be able to use it during the test it is a task that we consume for a long time the goal of my practice was to combine all the nuclear definition with similar work with the end of creating a standard variable base reducible that is suitable to perform the creation and configuration of virtual networks that will be used after the test this will help to create new network tests with ease and speed for example with those simple tasks you can create and configure the space of names, directions, routes, bridges, tunnels, etc. your idea of reducing the time that you could take to write these tests with the programming team you can focus on the task that you need that is to write what the test does this base module has the intention of setting it under the directorial tool testing set test net if this work is done internally between my team and these spaces are still pending to be sent it has been a great experience, clear, slow, and more useful to see how the community works, how it contributes, how it feels this is part of a community contributing from an open source the most part of this project is very well written I request you to learn from these complex algorithms and how to solve the problems hello everyone I am Shriya Patel and I am here to present my project called sound open firmware that is SOF for my Outreachy Linux kernel internship under the mentorship of Daniel Baluta so here's a little bit information about me I recently graduated as an IT engineer and I also work as a DevOps engineer at Volta's Clover since one year I have always been more interested in debugging and troubleshooting so I thought DevOps would be a great field to explore I also work as a freelancer on Upwork where I mostly deal with Linux kernel related projects and as you know I have also been selected as an Outreachy Linux kernel intern this year I started my journey with Linux kernel in my first year of engineering back then I did not even know how to install a Linux OS it took me almost three years to be here in front of you all so yeah it has been a pretty awesome journey now let's move on to our project what is SOF sound open firmware is an open source audio digital signal processing firmware infrastructure and SDK SOF provides infrastructure real-time control pieces and audio drivers as a community project why SOF what is so special about it SOF is developed in public and hosted on github platform and that is the specialty since it is very rare to see open source firmware it helps developers around the world to customize firmware for the devices they have in their mind it also improves the security of the system and ability for others to collaborate on it makes it even much better the main component in operating a DSP are a host and a DSP host has the SOF Linux kernel driver which communicates and instructs DSP on the other side DSP runs the SOF firmware and performs the processing as per the instructions received from the host now before I move on to the objective or goal of my project I would like to explain some components which I touched in order to better understand my project first is fuzzer fuzzer or fuzzy testing is done by a software component that generates random inputs and sees behavior of the system SOF fuzzer is an IPC fuzzer that loads and manufactures IPC to send two DSPs it acts as a host in our system which means we use a fuzzer instead of a linux kernel for now the process is the process for fuzzer goes something like this it first initializes the host platform establishes connection with the DSP reads the topology file sets up the DSP accordingly sends the first IPC signals our next component is QMU DSP emulator it is used on the other side of of fuzzer which means fuzzer will be on site A and QMU DSP will be on the opposite side which is site B it acts as the DSP QMU emulates the IMX8 DSP for example it emulates all the functions of the IMX8 which would include what to do on particular instructions how to react to some changes what responses to send back now the next part is messaging unit this is the most critical part of our project messaging unit is used for communication it has two processors one is processor A and other is processor B messaging between these two processors is done with four write only transmit registers and four read only receive registers which are present on both the side of processors also to control these messaging we have two more registers called status and control registers again on both the sides so finally how do we how does all of this fall together i have created a rough diagram to show the workflow here as you can see we have two sides side A and site B fuzzer is on site A which is acting as a host and QMU on which IMX8 DSP has been emulated is on site B in between we have shared memory and we have also emulated MU here MU A acts as the processor A which carries the messages from the fuzzer and MU B acts as the processor B which carries the messages from our DSP site so that's the kind of architecture and workflow here what has been my role in all of this we had a working progress implementation for IMX8 fuzzer that didn't work because MU was not emulated correctly and since there was no proper communication happening DSP never booted so to fix MU implementation I had to understand the components like fuzzer messaging unit QMU APIs or SOF firmware all these things are critical to understand to fully implement a testable emulation this meant a lot of digging and jumping around the code following function calls getting lost on the way doing it all over again so finally we came up with an implementation that successfully emulated MU and our pipeline was executed successfully now let's have a look at the terminal output of before and after phases for better understanding what changed after fixing the messaging unit in this picture as you can see I have highlighted a message which says DSP boot timeout platform IMX8 failed to initialize this means DSP waited for some time to get the message from fuzzer via the messaging unit but it never received it and hence it timed out after digging debugging and digging a lot of code we understood that there were problems with the messaging unit emulation in the next slide you can see the output where it says firmware boot complete which we finally got to see after correcting the MU implementation firmware then also successfully parses the topology file that we provided and that's the happy ending so I would like to conclude my presentation by saying thanks to my mentor Daniel Balluta I wish I could be his student forever there is a lot to learn from him a lot of thanks to Julia Leval and Jonathan Cameron for always supporting me throughout my Linux kernel journey even when I knew least about it outreachy coordinators and organizers have been amazing and did a fantastic job thank you all thank you for watching our interns and also thank you for their presentation and all their contributions to our community please sponsor outreachy or become a volunteer thank you