I want ideas on what I could contribute

[0xdeadbad]

I want to learn more and contribute to the project. I've been studying some parts of the Linux kernel so I have some idea on how those parts works.
But I'm not sure on what to contribute. What would be a good start to contribute with the system's current state?

[vvaltchev]

You're more than welcome to contribute. There are an infinity of things you could do, depending on your experience and the time + effort you'd like to invest in the project. It's great to hear that you have some experience with the Linux kernel.

I find for myself very useful to get in touch with a new project to start from the tests. Learn how to build & test Tilck. Here's an overview of all the 4 ways used to test the project: https://github.com/vvaltchev/tilck/blob/master/docs/testing.md

There are currently two opened issues, filed especially to introduce people to the project. Choose whatever seems more interesting to you, as nobody is currently working on them. One requires writing unit tests (C++), which run on the host machine and are easier to debug, the other requires writing system tests (C), which run directly on Tilck.

After you're confident with tests and you like contributing to the project, we could talk and find the perfect kernel feature/project for you. The project needs a lot of work in many areas. For example:

• porting to x86_64 (in progress)
• porting to ARM and/or AARCH64 (Raspberry Pi 3 and/or 4)
• Introducing support for block devices (which ones? we have to think about that)
• Introducing support for network devices
• Introducing support for sockets & all related syscalls
• Adding support for at least ext2 on block devices and optionally re-work the whole fat32 code to work also on block devices, not just in-memory.
• rethink about the locking of the whole VFS layer. Maybe more granular locking should be supported?
• make Tilck support more of the features of real-time Linux. E.g. scheduler, RT signals etc.
• support MMU-less systems and port Tilck to ARM Cortex-R systems

The list goes on and on. Unfortunately, I'm too busy to actively work on any of these at the moment as I have to focus on my job. But wishfully, contributors with enough experience and motivation could help me. Just, I have to say that it's not easy, as the quality bar is pretty high: this project needs to be rock solid, super fast and consume very little memory. To get that, we can sacrifice only features, nothing else.

In conclusion, I'd say start small, let's know each other first. Then, I'll slowly propose you more and more complex tasks, requiring an increasing level of coding, debugging & kernel-design challenges.

Vlad