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

[ciyizhou]

Hello @vvaltchev, I've just find Tilck and really appreciate its clean design and well testing. I'd like to contribute and have experience with ARM architectures (Cortex-A/R). Is there any ongoing work on ARM now? If anything I can try to start contributing? 😃

[vvaltchev]

Hello @ciyizhou, Tilck has no support for ARM architectures at the moment, while that's absolutely in the roadmap. So, there are no small/simple ARM-related contribution opportunities, unfortunately. The only one is porting the whole Tilck, step by step to ARM64 (aarch64) and make it run on Raspberry Pi. That is very close in size and complexity to the effort of porting Tilck to RISCV64. You can browse all the pull requests in that area to get an idea of the individual tasks. That total size of the diff was about ~10,000 LoC and the guy who did that was very experienced.

Doing such a port requires multiple years of experience with kernel development, so I wouldn't recommend that to most developers, but I know nothing about your background. You might be that person. Do you mind sharing something about your experience with operating systems?

[ciyizhou]

@vvaltchev Sure! For the past 5 years, I have been doing ARM-related low-level software development in my company , and I have read lots of ARM arch code in operating systems and hypervisors(Linux,freeBSD,xen...). But lack of experience in participating in open source. Maybe I can start from this.

[vvaltchev]

@ciyizhou Wow, that's great! In that case, it makes sense first playing a bit with the project to learn how to compile it / configure it / test it / debug it. Take a look at the documentation files in docs/, in particular contributing.md. Learn how to attach GDB, how to trace syscalls, how to use the serial port, how to write a simple module. Check the coding style, the abstractions and the semantics behind names, functions etc. Those things are important to keep the code understandable, extensible, etc. Take your time to explore the project. In OSS software it doesn't make sense to rush. We have no deadlines to meet.

Then, start working on a change in the build_toolchain script and related include scripts, to download a libmusl aarch64 gcc toolchain from bootlin.com, same as we do for the other target architectures. Then make the first change allowing Tilck to just compile for that target architecture. And move incrementally from there.
I have a preference for aarch64 instead of 32-bit ARM as a first ARM arch, because that seems to be more widespread for application-level CPUs (Cortex-A) today and because there aren't so many flavors of 64-bit ARM compared to the number of 32-bit ARM flavors. Too many calling conventions and CPU features sets on 32-bit ARM. On the other side, 64-bit ARM starts from a solid baseline common to all CPUs. ARM64 user software runs both on Apple Silicon and on RPI, which are quite different. Once we get that working on real hardware like Raspberry Pi, it would make sense to "go down" and support various 32-bit ARM flavors and more "embedded" boards. And, finally, in the long term, do major changes to support "nommu" ARM CPUs like Cortex-R. That will require a lot of thinking to get it done properly without breaking anything else. Even just compiling the userspace software to work on NOMMU will be a nightmare, as it would require a custom built uclibc, instead of libmusl (because there is no fork() etc.). So, let's leave that for the distance future.

The port to ARM64 should be conceptually straightforward since we already support i686, riscv64 and at early stages x86-64. Does that make sense?

[ciyizhou]

Yes, I also believe AArch64 should be consided first. Regarding board selection, I think starting with QEMU virt would make debug easier, support real hardware(raspi) gradually. A short development plan list I came up with:

1. Get a general understanding of Tilck—especially focusing on the boot process, from bootloader to the Tilck boot code. Memory management is critical, including memory layout and mapping.
2. As you mentioned, start with the build system and toolchain. Understand Tilck's current build strategy first. Create a new target for AArch64-based platform. Add new directories and configs for ARM in kernel.
3. Enable autotest as early as possible—the sooner, the better. Even if the initial test cases are few and simple, even only build verification?
4. Begin the basic adaptation work: setting up memory mapping, system register configuration, interrupt vector table, , board-level initializationetc. The UART should be the first device to get working.
5. Enable more modules gradually. enable and pass all tests.

The RISCV platform is an important reference, and I will start reading doc and code to know tilck more deeply.
Thanks, @vvaltchev

[vvaltchev]

That's great, @ciyizhou! I completely agree with your plan. It always makes sense to start with QEMU virt and get something working, then gradually start playing with real hardware. I mentioned RPI because it makes sense having that as the first AArch64 board to support, because it's super widespread. With RISCV64, we introduced the concept of "BOARD" in addition to the "ARCH" (target architecture), so that should help supporting multiple boards for the same target architecture.

Of course, just build verification is all we need initially, until we have something working. All the arch-specific functions could be implemented as stubs e.g. void map_page() { NOT_REACHED(); }.

Beyond the build, the first step is to decide how are going to boot on aarch64. On RISCV64, the contributor used UBOOT which seemed a solid solution reusable for AArch64 too, if you don't want to write also a bootloader, which is a lot of work. However, with just UBOOT, we lost the possibility of booting using qemu-system-xxxx -kernel <tilck> on RISCV64 while that was a nice feature to have for testing, because we can use -append <args> etc. It's totally up to you if you feel inspired about supporting the Linux boot protocol on AArch64, in addition to UBOOT, so that we can have that extra feature, for testing purposes.

After booting, the first challenge is setting up everything in start.S in the respective kernel/arch/$ARCH directory, so that we can enter in the C function kmain(). There we clear the BSS region, setup paging with identity mapping, enable CPU flags, convert registers with pointers to boot data structures to arguments for kmain() etc. Then, once in kmain(), if the serial port can be initialized, we can finally print "hello world" :-)

I'm looking forward to work with you.

[ciyizhou]

This additional note is very helpful. Let's get started. I’ll reach out to you once I’ve made some progress.