Tips for (not only) students

On this page, we provide tips for authors of HelenOS master and bachelor theses, various software projects and Google Summer of Code participants. However, many of the tips can be generally helpful to any contributors to HelenOS. The tips are based on previous experience in this area. For official guidance, please consult your thesis / project advisor, supervisor or mentor.

Coding tips

Implementation

• Do not impose artificial limits on your implementation. If your project is fundamentally platform-neutral, for example when what you implement is a sophisticated data structure or a new file system, do not restrict the implementation to a single supported processor architecture, byte order or word width. Remember that HelenOS is a portable multiplatform operating system. Your generic code is supposed to run everywhere where HelenOS can run. This ranges from small little-endian ARM devices to much bigger multiprocessor 64-bit big-endian UltraSPARC servers.
• Stick to the HelenOS coding style. We really mean this. Your failure to adhere to the coding style of the surrounding code requires someone else's extra work to perform the cleanup after you. The fact that you may prefer another coding style is quite insignificant in the context of HelenOS. Get over it and use our coding style.
• Adhere to good coding practices, such as adequate commenting, avoiding dense code, using horizontal spacing as visual delimiter and keeping the block nesting level under control. Also pay attention to seemingly subtle and unimportant decisions, such as proper naming of identifiers, following a coherent naming pattern, etc. Remember that the code is written once, but read many times. Do not make it harder for the reader than it is strictly necessary.
• Self-contained code is good, but avoid poorly integrated code. Poorly integrated code is pointlessly concentrated in one subdirectory of the source tree. For example, putting new generic ADT's and IPC primitives under the networking directory is a sign of poorly integrated code.
• As with the text of your thesis, similar citation rules should apply in your code. When using third party code, always give credit where the credit is due, always follow the license of the third party code. It would be kind of embarrassing to discover portions of e.g. Linux header file in code which you advertise as yours.
• Be open-minded. If you are designing a new subsystem or some sort of interface for HelenOS, it may be convenient to do it exactly how it is done in e.g. Linux. Please don't do that, especially not if the only reason would be because Linux does it that way. Remember that cloning a legacy system is not our goal. When evaluating approaches to a problem in other operating systems, use critical thinking and try to find problems of and ways to improve their solutions.
• Always use English for writing comments.

Licensing considerations

• Resist temptations to borrow code from GPL projects as most of the HelenOS code is BSD licensed and doing so would automatically switch some of its components to GPL. We don't want this, so don't do it.

Testing

• Make sure your changes do not break the build of any of the supported configurations by running make check.
• Always test on as many architectures and configurations as possible. When applicable, test your changes on both 32-bit and 64-bit, little-endian and big-endian machines, single processor as well as multi-processor builds and configurations.
• When possible, test on real hardware too. The use of real hardware is essential especially when doing performance tests or testing a new device driver or platform code.

Source history

• Remember that the revision control system does not forget things. Whatever you commit to your local branch will often eventually be merged into the HelenOS mainline repository.
• Always use English for writing commit logs.
• Give some extra love to formulating your commit logs. You may consider providing one summary line followed by an empty line and a bullet list of more detailed description of each change.
• Try to make more smaller commits than few larger commits.
• Unrelated changes should go into separate commits.
• Don't forget to review your changes before committing them and avoid committing unintended changes (temporary hacks, purely debugging stuff) by accident.

Writing tips

This section is only relevant to you if one of the outcomes of your project is some kind of a written publication such as a paper, a thesis or design documentation.

Content

• If you provide some sort of HelenOS overview chapter, please do not blindly follow the pretty much outdated 0.2.0 design documentation (i.e. forget about pseudothreads and use the current terminology) and stick to the things that seem relevant to your own work (e.g. no need to provide in-depth description of the kernel architecture if your focus is on some userspace application). There is also no point in retelling the early history of the project in each thesis.
• If you provide a related work chapter, consider providing comparison with similar microkernel multiserver operating systems (if applicable), i.e. the Hurd, L4 and MINIX 3. These will be very interesting and useful as you will be comparing apples with apples and not apples with elephants in case of comparing HelenOS with GNU/Linux or any other monolithic system.

Form

• Always differentiate your own words from words of someone else by providing proper citation information. Never let other people think that some ideas or words are yours whereas in reality you just saw some handy text or used some notoriously known phrase. Note that these things can happen even ​unintentionally.

Planning

• Getting the thesis into a good shape (grammatically, stylistically and visually) can take as much as half of the entire time you reserved for working on the text of the thesis. People don't usually believe this advice or don't take it seriously enough, but then all of them are found to have a very eventful and exciting submission week and the end result is not as good as it might have been if more time was spent on editing the thesis.
• Most of the time, there will be people willing to proof-read your thesis, so plan ahead to allow enough time for these proof-readers to do you this favour and also to incorporate their suggestions.

Social interaction tips

Interacting with the community

• The HelenOS community can provide invaluable feedback to your ideas so make sure to interact with the community effectively. Simply put, participate on the mailing list and, if possible, attend the monthly project meetings.
• Prefer open communication on the mailing list over one-to-one private communication of any sort.
• Consider hanging around on our ​IRC channel.
• Don't be shy, we don't bite.
• Nobody's perfect.