halos-devel — List for developers to discuss on

[Ronald Landheer-C. <ro...@la...>]

Hello :)

I've just processed a few requests for people who want to become 
developers on either the Halos project (this project) or the Jail 
project. There is one developer that confirmed an interest in joining 
this project - the others are more interested in joining Jail - so I 
thought I'd post an update on what's being done and what needs to be done.

Current development status
==========================
Currently, before anyone being added to the project, there are two 
developers here: paercebal (Raoul) and myself (blytkerchan, rlc, Ronald) 
and there are three areas of active development:

    * a file system, rfs
      Raoul, could you please explain (mostly for the newcomer(s)) what
      the goal is and what the current status of development/design is?
    * event handling
      The API is done, wrappers are installed at start-up but the code
      is completely un-tested. IA-32 arch-dependant code is there (but
      un-tested), other architectures aren't.
      There are APIs for exception, IRQ and general interrupt handling,
      which should just work. However, the APIs are very
      architecture-dependant because the restrictions on their use
      (preconditions) are.
    * memory management
      segmentation is in a design phase, as is paging. I'll start
      implementing segmentation handling shortly.
      There is no allocator yet - anyone is welcome to implement one.

Directory tree hierarchy
========================
The CVS is set up as follows:

    * the filesystem is not in CVS yet, when imported, it should follow
      the same guidelines as the other modules

each of the modules is rooted in the CVS root. Other than the modules, 
the CVS root contains the license.h file (see licensing below), a change 
log and a list of authors. The list of authors will be updated for each 
new developer added to the project.

Each module (except for klib, doc and fs) has the following structure:
    + module
    \--- <arch>
For example, event contains one directory, event/i386. All the 
architecture-independant code is at the root of the module's directory; 
all the architecture-dependant code is in the directory with the 
architecture's name. When checked out, the name of the architecture is 
replaced with ''arch'', which allows, for example, an i486 architecture 
to also use i386 arch files.
Now here's the important part:
Referencing *any* function in architecture-dependant code makes your 
code architecture-dependant - meaning it should be in a directory named 
for the architecture it depends on. There *are no* exceptions to this.
That said, I have already broken my own rule in tools/cpu-info, but that 
will be repaired shortly.

Programming languages and coding standards
==========================================

    * Any assembler code is written in AT&T syntax.
    * As much of the code as possible should be written in C
    * C++ code is only admissible if there is a valid reason to use C++
      and not C
    * No other programming language may be used

When writing C (or C++) code, make sure that you do not depend on *any* 
standard library functions: all we have is klib, all you need should be 
there and, if it isn't, should be added. (Currently, there is almost 
nothing there, so basically everything should be added).

When writing a new feature, if possible, write it in a user-space 
harness first, and add that harness as a tool to the tools module. This 
allows for far easier testing.

Hungarian notation is banned - name functions and variables for scope 
and functionality.

ISO standard compliance is mandatory. I am not a language lawyer, but I 
do have a copy of both the C and C++ standards and will check them if I 
find anything odd.

Other standards will be made up as we go. Have a look at existing code 
to get a feel of what new code should look like. When in doubt, discuss 
it on this list.

What needs to be done
=====================
One thing that would be nice is a slab allocator to be used for both 
memory and drive space. This should require no assmebly code, but may 
have to use some arch-dependant APIs.

Another thing that needs doing is a driver for the console, for IDE 
drives, for debug output ports (as found in Bochs, for example), etc. 
This will require some assembly.

Licensing
=========
Contributions should be licensed with a license compatible with the 
GPL/BSD double license. The exact license is the choice of the author.

The GPL/BSD double license allows me, rlc, as project lead, to allow 
contributors to use the code under a BSD-compatible license while anyone 
else is bound by the GPL, meaning they must open their source if they 
want to use ours. As I do not have the right to waive a copyright 
license of code I do not own, the contributors code should be under a 
license already compatible with BSD. Due to its (presumed) dependancy on 
other code under the GPL/BSD double license, the GPL will automatically 
apply as well.

The reason for this scheme is to encourage business contributions - as 
businesses rarely want to open their code with GPL.

Committing to CVS
=================
No-one has carte blanche on CVS - and that includes me. There is a 
halos-cvs list which sends the patches committed to CVS. You are 
encouraged to subscribe to it and scrutinize anything that comes by. The 
earlier a bug is found, the better.

That said, you are implicitly trusted on any code you own/maintain, so 
the CVS ACLs will be adapted to allow you access. Access to any other 
part of CVS requires going through this list.

Comments are welcome: I by no means intend to impose anything on anyone, 
but this setup works for me :)

rlc