Disclaimer: This page is just a front-end for what we plan to be done. If you need a more detailed information about the project progress, please consider watching the Sourceforge Tasks system instead ...
Discussion and decision of what is to be done and how we'll do it is located on eyeCandy forums (follow the icon)

The Clicker project -- what's still to do

Emergency Very High High medium low research dream fix

Documentation Writing (Emergency)

Complete description (in english) of major Clicker mechanism and design issues
kds: how does modules work, what are Slang, KDS ... vvvv
kds: About KDS policies, KDS2 extensions, etc. vvvv
threads: thread programming interface, scheduling & dispatching, threads destruction, XLR8 extension vvvv
einstein: memory programming interface, lostzone algorithm, blockman role vvvv
manuals: Better installation notes vvvv
manuals: How to use Clicker debugging facilities vvvv
Global System Overview: vvvv
Api: Api & KDS namespaces documentation vvvv

Working teammates: Pype & Paul B


multi-mode modules (High)

We currently have 2 kind of modules: synchronous and asynchronous. The goal of this task is to update the module loader so that it can handle policies. The module type will resolve into a list of functions that will describe in what kind of memory the namers should be allocated, what is the virtual 'root' of KDS naming space for this module, etc.
module policy description: Define what kind of feature the policy will have to handle (this is a kind of interface). Only the things that has been described in that policy will be configurable. vvvv
microkernel module policy: Translate the actual behaviour into some module policy. vvvv
module policies extensions: Allow KERNAL modules to bring up extensions to the existing policies. One easy way to provide this is to describe a service interface (services.sys.modules:policies ?) that the generic module loader will call, and a message dispatcher that will look at the module type request to bind it to a specific module type. vvvv
domain support: A KDSDomain is a sub-space of KDS which has its own memory allocation policies, its own interner, etc. A wrapper should be also added so that the request could be queued to a given process, distributing the actual KDS information among several process, each of them handling a specific sub-set. vvvv

Working teammates: -nobody-


Events processing Engine (Very High)

Events will be one of the most used way for interprocess communication in Clicker. They act as a kind of improved signal handlers for developers that are comfortable with Unix programming, but with much more flexibility in attributions of messages IDs (so that events can be used to inform of a button click as well as a broken pipe or a timeout condition). read the mission statement here
events structure: Definition of messages, queues, etc. vvvv
kernel-to-kernel events: Special case of events being handled by kernel code. required for many device driver features. vvvv
user-level events: Let user-level code issue events and setup user-level handlers. vvvv

Working teammates: Rajeev & Pype


KDS 2.0 (Very High)

There are still several drawbacks to the actual KDS system, mainly concerning the ease-of-use. Next version of KDS should focus on simplifying module developers' life. The mission statement for KDS 2.0 is available here.
automatic and safe ksyms.* importation: get rid of the import() slang command that makes the module crash when the symbol is not found or when the import() command is forgotten vvvv
modules dependencies counter: prevent a module to be unloaded while other modules relies on its presence (through import/exports) vvvv
automatic generation: of API messages and inline callers for KDS services from the server/service definition A perl script has been written for this, now we have to generate stubs for microkernel services and document the feature (a kind of update to the slang manual) vvvv
constants: Support for atomic constant values adds from a 'module' rather than only pointers vvvv
KDS OČ: Complete support for Objects in KDS and quick creation of their recognizers. vvvv

Working teammates: Pype


Generic Device Driver Programming (High)

Lots of things are to be made before we can see a true device driver developped for Clicker. This gives an overview but is certainly far to be exhaustive:
buffers: support buffer-class memory (should be able to define how much memory the system will allocate for I/O buffers - DMA trouble). Also need a way to allocate contiguous physical memory vvvv
allocation: generic management of hardware resources (which irq/dma channel/ io ports are available and which aren't) vvvv
timer wake-up: This will require events to be available. So we should at least define the Events Programming Interface (see events engine proposal). vvvv
Q-threads: (threads that can be activated from any address space - for IO handlers in "microkernel extension" boosters) vvvv
Driver Programming Interface: how will a device driver offer services to the rest of the system ? Do we keep char vs block semantic of unix? Doesn't we need new abstractions of device drivers (streamers for audio & video, for instance)
A first attempt on the definition is available here 		vvvv
Config: support for configuration files (we first will suppose that config values are in KDS and further configuration instances will write values read from config files vvvv

Working teammates:


Memory Management Extensions (High)

Allow the construction and the use of memory objects wider than 4 Mb, build tests for such memory objects. Rather than directly modifying the pager code, the modifications should be carried out in pager-II module, mainly at the cluster and the page table interface.

The "zone" interface is targetted for allocation of memory within a page table, so it shouldn't be modified by this mission. read the full mission statement

page tables flexible allocation: get contiguous range of page tables vvvv
page cluster: allocation of zones larger than 4MB vvvv
autoselect: region-based clusters with automatically-selected base address. vvvv
support for KMEM_PINNED memory vvvv
final tests: vvvv

Working teammates: Kuldeep


Better tools (High)

Improve the development toolkit. This should include the ability of compiling the whole kernel under Linux (and thus either developping elf version of the binary utilities like modmaker and progmaker or developping/downloading/adapting/whatever a elf2coff converter), an improved version of the bootmaker tools (able to fully create a boot disk from MS-DOS)

Working teammates: -nobody-


True Display Driver (High)

For now, SOS perform basic display management. The goal of this task is to introduce a true "console" structure that will interface between the raw devices and user programs. 
Keyboard/Screen drivers: vvvv
scancode-> ascii: character converter vvvv
console resource class: (in and out) vvvv
console swap support: allow multiple user program to have their own separate display buffer. vvvv
mode switch: magic 'sysreq' key to switch between kernel/user console vvvv
video: VBE 3.O framebuffer vvvv

Working teammates: -nobody-


Complete process support (High)

Have process cloning with a "fork" command, programs loaded from files (including blocks reads rather than counting on a preparsed memory image) Support interprocess communication (with mailboxes and events), process destruction by kernel (the crash task should be able to kill processes and recover) and true PIDs management.

Working teammates: Girish


Disk Driver (High)

The goal of this job is to create a support for IDE-compliant hard disks as a module to be plugged into the microkernel. In addition to read and write sectors to the disk, this module will also be responsible for enumerating the available devices and extract their partition table. read the full mission statement
DIB: Define the "information interface" for a disk Devive (Device Information Block). The DIB is now available through kds://system.device.<class>.<dev> vvvv
AtaScan: devices enumeration module is almost complete. Just make sure it will report every useful information. vvvv
AtaKds: access provider to devices informations. A KDS2 object recognizer has been added so that one can browse the information. Among other things, the features list can be viewed. vvvv
ataQueue: block driver service (read & write sectors from given drivers). The service is at kds://services.dev.disk:block. So far, only reading is support and is at experimental level. vvvv

Working teammates: Paul K. and Pype


User level support (medium)

The first test of userlevel programs have been passed sucessfully, now i need further tests, mainly to validate resources handling. For the first tests, the program interpreter is launched with a memory image of the user program in kernel space.
develop a 'PROG' memory object vvvv
implement the resource segment of process vvvv
develop basic resources (process itself, message output) vvvv
write the program interpreter that will build user process vvvv
small test module (user program embedded) vvvv
tests: vvvv
automated program generation vvvv

Working teammates:


Demo FileSystem (medium)

That's the next major step to be added to Clicker: a file system. the task includes a disk driver (most probably IDE disk at the beginning) a file organisation (CFS1) that should be extensible for the future and a resource class for managing files.
bootdisk: creating bootable diskimage from a makefile vvvv
bootsos: native SOS boot system (no more DOS dependent) vvvv

Working teammates: -nobody-


Clicker Shell (low)

Working teammates: -nobody-


Interface between user programs and KDS (low)

Working teammates: -nobody-


Graphical user interface (research)

Working teammates: MuadDib & Pype


Ethernet & TCP/IP stack (research)

Working teammates: -nobody-


Find a way to write the code without all those #defines (dream)

Working teammates: -nobody-


What still stinks in Clicker Code

Not yet issued

  • Too much demo programs use direct access to default console :-/
  • Most of the virtual memory components assume nobody will reclaim zones wider than 4Mb :'-(
  • The package of modules loaded by SOS behind the kernel (a kind of ramdisk) is called "disk.img". One could get confused and try to put it on floppy as a disk image to be booted... disk.img is certainly no bootable image! it should be renamed %-@
    •

    Partially resolved

  • Modules are tricky to create! All client stubs of KDS must be written by hand, symbols must be imported manually, messages structure must be declared by hand, etc.
    KDS 2.0 should solve that problem by automatically creating a .api file out of the server / interface definition. With the help of C++ namespace, producing these API files shouldn't be too complicated.
  •  The process ID allocation is a shame
    litlle improvement in 0.7.16 : now the pids are provided by an upgradable KDS service rather than by hand. Girish is also working on a more complete and efficient version of the PidTable service.
    • We should define a "services.sys.file" instead on using savage "SOS_map"s
      fixed: kernel version 0.7.19 uses that service for modules loading. It can also provide a "file" facility through the sfsFileImage interface.As part of the complete support of exec() and exit() system calls, Ognen will also upgrade that service for listing the available files, etc.

    Fixed

  • The way we create user-level program is not dign to reside on the Net
    fixed: a new tool - program maker - has been develop to cleanly produce PROG files out of coff files. It only handles very simple programs for now (single-thread, single memory object), but at least it does the job cleanly.
  • Core memory management algorithms are still written in ASM
    fixed: since v.e.r 0.7.22, both the memmap and the lost zone (block allocator algorithm) are written in C and are among the cleanest pieces of code for the whole kernel. Moreover, the new Memory Map system deals with pages classes (buffer, swappable, microkernel, etc.) both at allocation and dellocation
  • We still can't boot from a floppy disk
    fixed: now we can, but the tools to create diskimages are still hackish




    • Pype