Since I wanna get the most of my experience from my LFX mentorship, I decided to set some goals.

As I decided to participate as a 'full time' mentee, I thought I could go beyond just choosing two kernel areas and could have some well defined general goals and a sort of a 'roadmap' to help me stay focused during my journey.

This post is my intention to 'compromise', I mean, if someone could be watching it's harder for me to slip on the process.

Areas of Focus

So, first my areas of choice to focus -- the ones I'm actually expected to select. I decided to go for one area where I'm more comfortable and one area that would be more challenging.

So the two areas are:

• Virtual Filesystem (and related, i.e., namespaces)
• Memory Management

The virtual filesystems is the one I'm more 'comfortable'. I mean, I'm far from being an expert or any sort, but I have already touched and studied some of it before. I discarded some subsystems where I had previous upstream contact, like the staging/ area, even though I plan on finishing an old patch on it. I mean, the staging/ area is an important subsystem for the kernel process, but it's a place where I already did some work in the past and the drivers are quite random and mostly stuff I don't have, so I would be contributing for numbers only.

I had some net & net drivers exposure downstream, but again, I'm afraid they might involve some complicated testing setups that would shift my focus from contributions.

The virtual filesystem is something I already have a minimal grasp but the kinds of setups necessary for testing is more stable and I have some few ideas about what to work on and some previous contributions, so it seems more comfortable.

The second one, memory management, well, it's supposed to be the challenge. I mean, I have only an obscure vague notion about mm and learning it helps a lot understanding other areas. I see it like a critical skill.

Goals

I divided the goals in direct goals and indirect goals. Direct goals are the ones directly related to the mentorship. Indirect goals are the ones that relate to other personal goals and will be helpful to achieve during the program.

Direct Goals

1. Studying Virtual Filesystem
2. Studying Memory Management
3. Study the proposed tools and resources
4. Contribute beyond graduation requirements (maybe roughly 15 patches?)

Indirect Goals

1. Reviewing patches as my knowledge allows
2. Building smaller configs and other resources to accelerate compilation time
3. Build a minimalist userspace using musl/cyrenit [1]
4. Fixing problems that are pains of my own
5. Building community relationship and trust

Rationale

This list of goals derive from, obviously, the mentorship requirements, but also from other things in my objectives that make the mentorship experiene more real-world and making sense for me.

For instance, I need to work on my soft skills and code reviewing. That will help me learning how to make good reviews, and being honest, code reviewing is a skill I lack. Most of my life I worked either on small teams or as a freelancer, and when I worked on bigger team sizes I didn't stick long enough to review code, and that's a professional gap I need to work through.

Objectives 2 and 3 are somewhat related to my own hardware limitations. My skylake processor wasn't that great in 2019 and it's quite behind most cpus of today. Compiling the Linux Kernel takes time. I'm doing that to optmize the process. Also, it aligns well with my future intentions with cyrenit.

Objective 4 has an obvious side: fixing problems that are pains of my own are a way to stay grounded and work on things that really make a difference for me and it helps ensuring I'm doing a realistic work.

And building community relationship and trust is, well, part of my intent of working with the upstream community in the long run. And also meaningful for me because, well, I use Linux since 2002.

Roadmap

This is a work in progress, but I'm trying to express how I see what I have ahead. We are soon entering the merge window, the things I have for working right now won't be finished until it starts, so I'm gonna focus on sharpening my skills and preparing for the challenges after the merge window closes.

In that sense, I decided to draft a roadmap like this:

Merge Window 1:

• Work a lot on my kernel configs and minimalist workspace
• Study the VFS subsystem a little a day
• Since the merge window limits community interaction, use KernelNewbies project to build community a deeper relationship with the community
• Learn the suggested tools that are more helpful to detect issues and produce scripts to find work to do (i.e. coccinelle)
• Review regressions and syzbot bugs - analyze 2 bugs and 2 regressions
• Strengthen my weaker spots (locks, rcus, etc)

Weeks from rc1 to rc3:

• Resume my old staging patch
• Work on my acer laptop wmi driver patch
• Pick 1-2 more cleanup/refactor patches on the vfs filesystem to build trust
• Study the proposed tools that are more related to testing and improving the quality of my patches (i.e. selftests)
• Work on 1-2 documentation patches I have in mind
• Dive deeper on studying vfs
• Review 1 syzbot and 1 regression per week
• Follow 3 patch discussions per week
• Target: 5 submitted patches

Weeks from rc4 to rc6:

• Start studying memory management subsystem
• Find a few small tasks to work on the mm subsystem and submit 1-2 patches
• Practice my learning from previous weeks and submit 1-2 related patches (i.e. kunit or kselftests)
• Review 1 syzbot and 1 regressions per week
• Work on 1-2 patches from syzbot/regressions
• Follow 3 patch discussions per week, 2 on vfs
• Work on received reviews from patches from the previous weeks
• Target: 5 submitted patches and 1 submitted reviews

Weeks from rc7 to tc8:

• Dive deeper on studying mm
• Work on 1-2 patches on the mm subsystem
• Follow 5 patch discussions per week, 3 on vfs and 1 on mm
• Investigate an umount2() limitation I have been studying and submit and RFC if promising
• Investigate whether an initcall macro refactor would be justifiable and prepare an RFC if the benefits are complelling
• Work on received reviews from patches from the previous weeks
• Target: 2 patches, 3 RFC patches and 2 submitted reviews

Merge Window 2:

• Study deeper the vfs and mm subsystems
• Study deeper tools that I still have room for improvement
• Work on feedbacks received on the patches/RFCs
• Follow 10 patch discussions per week, 5 on vfs and 3 on mm
• Plan for the next cycle

NOTES

[1] Cyrenit is my minimalist init (PID1) program.