Contribute

Contribute

KoraOS is still really immature as I didn't manage to deliver a proper runnable kernel yet. However if, like me, you think it has potential and you wanna help, you are most welcome on my tiny dev-team.

There is lot to do, but no easy way to get on board, so I will use this page to lay down as much information as I can to help fellow developers to hack my project.

Development stack

In order to ease the development process I tried to make each block as portable as it get. So most of the components, tests and even some part of the kernel can be run on your host machine. I tried to test most of them both on linux and windows.

However as I can be really handy, for a new joiner I recommend to start building the full system and for that there's some setup to do. The reason is that you will need to cross compile every command and library with a new environment, new runtime and most of the time for a new architecture.

The only safe way to do yet is to use a cross-gcc build. You can build your own using the script var/src/cross_gcc.sh on the distribution repository.

You may require also some extra packages like : nasm for i386 assembly or lcov and valgrind for tests.

If you need any help to contribute, please send me a mail and I will add you to the Slack project.

Where can you help

For the moment I identify only a small part of the story that can be taken by contributor. I use a Github project to regroup all issues.

I will try to get more thorough about issue reporeporting as the team grows.

How to propose a change

At this stage, I'm not about to refuse contribution in any form I accept mailed patch as much as pull-request.

I'm not requesting completion for opening pull-request. They're a great way to get feedback to get help during the implementation. As soon as you get some code, you can open a pull-request. It allows others to see what you're working on and send you early feedback.

Note: Some issue have been tagged 'step-by-step'. For those one I will request to work on an opened pull-request as I want to check along the way the decision that have been made. I put this tag on key components that will have a significant impact on the rest of the project.

Tips to debug

Debugging a kernel is not always as easy than a regular application. Let's share here our tips to investigate bugs.

Gdb

One really handy feature of qemu is remote debugging. You can connect a gdb instance to run the kernel code step by step.

You just need to add to qemu the options -s -S. Then qemu will wait to continue. Run the debugger with the kernel binary: gdb path/to/bin and run the command target remote localhost:1234 to connect to the process run by qemu.

Testing tools

cli_vfs

On the kernel utilities you can find this small shell (under development) to test any file system drivers. The shell allow you to load kernel modules as library, load image disks (*.iso, *.img, *.vhd) and run request to the file system. You can also use predefined scripts to automate testing.

Code quality and style

Code Quality

The system is still young and although if I'm picky on code quality I won't refused code that doesn't follow strict guidelines.

Just try to follow the style of next piece of code. However don't get frustrated if someone go back to fix your code. It almost impossible to write perfect code on the first time. Software engineering is all about rewriting, rethinking and optimization.

Coding Style

For styling details I use the astyle command for all .h/.c source files. Please try to follow the rules but some divergence over time is expected. I only run the command from time to time to ensure quality is not deteriorating to much.

astyle astyle --style=kr --indent=spaces=4 --indent-col1-comments --min-conditional-indent=1 --pad-oper --pad-header --unpad-paren --align-pointer=name --align-reference=name --break-one-line-headers --remove-brackets --convert-tabs --lineend=linux --mode=c -r "*.c" "*.h"

• Accolades { are put on a new line for functions but not for inside blocks.
• Tabulation are replaced by 4 spaces.
• Comments are aligned with code.
• Spaces are used around binary operators.
• A space is used after block keywords (if, for, while...)
• No space between a functions name and its arguments parenthesis.
• Pointer qualifier are put on identifiers side (char *ptr instead of char* ptr)
• No need to add accolades for single statement blocks.
• Please use only linux ending lines (git config core.eol lf).

Architecture

As a kernel is a sensible system that need to be both robust and efficient, I put quite effort on clean and smart architecture.

As an hobbyist project I prefer to take my time to design correctly the system. I always preferred well thought, small pieces of code than over-engineered solution.

It doesn't mean architecture is perfect, it means it's trying to be. To achieve this, he should avoid dependency to the maximum, share common vision of the goal to pursue and take time on key components.

As the owner I do have the final say but I don't want to take all decisions alone as I think that an architecture that can only be understood by a few people is ,by definition, a bad design.

So come help and challenge this project!