|last review 2.3.2
I believe in Open Source and Clicker has been made possible
thanks to open source softwares like NASM, DJGPP, Linux, mozilla, Dia,
XMMS and much more.
However, i can't force people to join the FSF and ignore the fact that some
code to live, while others live to code ...
As a result, the microkernel of Clicker has been made OpenSource and
is (and will be) distributed under GPL. This do not mean that the whole
OS will have to be open-source: If SGI decide to port their closed GUI to
Clicker, that must be legally possible. Components that communicate with the
microkernel are not part of the microkernel and therefore aren't
concerned by the microkernel license. The system specification (how
components talk together) should - however - be made public as often as
Micro-kernel based system
As Mach and the first versions of SkyOS, Clicker32 plans
to be a microkernel-based system. This means that most of the system
services are running independently from each other in some dedicated
Microkernel architectures are known to gives better results in terms of system
stability. The microkernel is a small piece of code (typically under 256K)
that ensure base services (like physical memory management or task switching)
and communication between user programs and servers.
Preemptive multihreaded kernel
Clicker gives the best of what you could expect from your CPU
by implementing at kernel level a
environment, leading to reduced overhead when new tasks are started. Unlike
most hobby OSes, Clicker is from early versions a preemptive system,
which means it doesn't rely on user programs to have a correct multitasking
(not unlike Win3.11 and MacOS 8). The usual 'time slicing' model should be
improved with a support for
- giving the ability of having fast response from user-level code to some
hardware or software condition.
One of the major approaches of Clicker architecture is its
native support for modules - pieces of software that can be loaded
dynamicly in the microkernel. Those modules can be demonstrations, debug
plug-ins, system add-ons (as support for new programming environment), device
drivers or even a new scheduler.
It's quite an unusual feature of having modules facility in a microkernel
system. The idea is to let system operator (superuser) whether he prefers
to have a service within the kernel or aside of it based on the trust he
puts in the service.
Integrated Debugging tools
A powerful debug system is provided with the kernel, mainly
made of multilevel configurable logs and of interactive supervising consoles
giving the system operator the ability to kill process, monitor memory usage,
start and stop modules by simply browsing some information pannels
Developers also have the opportunity to make the kernel run 'step by step'
by placing anykey() function in the code. A special flag __DEBUG__
can control the generation of debug information to switch between
easily debuggable or lightning-fast microkernel at compile time.
Highly dynamic informations and linking system
A unique component -
Kernel Dynamix System
- provide information exchange between all the system's components.
It can be used to link modules, to store supported video modes as well as
for identifying the loaded modules or the number of available CPUs. Some
extensions should appear soon to extends that component into a user-queriable
database that could support object abstractions.
Secure Memory Model
Clicker uses the full power of the x86 MMU architecture
to provide a more secure programming environment, using protection at both
paging and segmentation units (unlike most system
actually do). This don't only protect the kernel from being corrupted by
a user-level program, but it also guarantees that nothing wrong will happen
due to a kernel stack overflow and that attacks like buffer or stack
overflow can't do any harm to the system by strongly separating the writable
and the executable bits.
Recent readings on other processors architectures convice me that such functionnality
could be extended to other architectures like Sparc or PowerPC
machine with little overhead.
Tunable OS abstraction
Many of the system components can be re-instanciated by some system
developers. The whole system philosophy is to keep the implementation free:
the system only describes the MULTIPLEXING of resources by some standardized
API and provides default abstractions (implementations) of these resources,
but the system operator has the power to define new implementation and to
define which precise implementation of a service an application should get.
Memory objects, file classes, volumes, etc. are all based on this concept.
call it a microkernel, exokernel, or whatever: this is just the Clicker
Device Drivers Framework
The system is at least ready to host your device drivers. A demonstration
IDE devices scanner and a small read-only ATA PIO disk driver have been
made available. A rationale broker model has been used to identify features
offered by the devices, and which of them are supported or required by the
drivers (so that we can easily have "USB device require a driver with VID=8086"
or "driver requires a disk that can deal with LBA addressing" or
"driver utility +20 if the disk can support ultra-dma") and helps selecting
the driver that will be the most "useful" for a given device.
Are you Ready For the New Generation ?