Version 5 (modified by 14 years ago) ( diff ) | ,
---|
Tips for authors of HelenOS master theses
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 stick to the things that seem relevant to your own thesis (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 multiserver operating systems (if applicable), i.e. the Hurd and MINIX 3. These will be very interesting and useful as you will be comparing apples with apples and not apples with elephants.
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 favor and also to incorporate their suggestions.
Implementation
- Stick to the HelenOS 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.
- 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.
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.
Note:
See TracWiki
for help on using the wiki.