Fenix logo

WARNING! UPDATING! The text below is being updated. Stay tuned! (2003)


Fenix is a project which aims to make it possible to let GEM, the OS of the Atari ST/STE/TT/Falcon to live on. It was initiated by Sven Karlsson of Istari Software.

Project start: 960412

News added:

  • 970412 microkernel renamed to nanokernel. More accurate kernel info. Descriptions on the various new features of the kernel.
  • 970528 Added Fenix logo
  • 980108 Updating...
  • 980722 Updating...
  • 981203 Updating...
  • 990208 Updating...
  • 990607 Updating...

  • What is Fenix? and Why?

    Fenix is a total remake of GEM,BIOS,XBIOS and MiNT. Why should anyone make a new MiNT?

  • Well one reason is that MiNT is now a very old prog which has been patched a lot of times. A remake would be a fresh start.
  • Another reason is that MiNT is a monolithic kernel and does not support virtual memory. It thus consumes a lot of memory.
  • MiNT does not support threads and has no true message passing.
  • Fenix will support theads,virtual memory at kernel level and a very fast message passing scheme.

    How should we do it?

    Fenix is very influenced by mach 3 and thus consist of a very little nanokernel which only handles context switching,paging, monitors, semaphores, lowlevel memory allocation and deallocation, server and shared libraries and message passing. Everything else is handled by threads, called servers, external to the nanokernel. This means that the nanokernel lies in resident memory and the rest is in virtual-memory. An additional benefit is that this scheme increases the portability of the OS.

    Processes, threads and threadgroups

    In MiNT and Unix a process consist of a context and a memoryspace. This means that it is hard to have several contexts running in a program. Nearly all of the new OSes have threads instead of processes. A thread is basically a context. A unix process is emulated in Fenix by a single thread in a single threadgroup in a memoryspace. The concept of threadgroups is also used. A threadgroup is a collection of related threads ordered hierarcly ie there can be groups in a group.

    Programs

    Programs in Fenix originally consists of a memoryspace and a thread. Additional threads can be spawn by all threads and don't need to be copies of the spawning thread.

    Memoryspaces

    This is a new concept. In MiNT there is no need for this since all memory is bound to processes. Memoryspace is only a collection of memoryblocks that some threads can run in.

    Thread Signals

    All synchonization primitives including message handling is built ontop of a generic synchronization system based on something I call "Thread signals". Thread signals are similar to ordinary UNiX signals. Each thread has 32 signals of which 8 signals are fixed and used by the system while the rest can be used freely by the application. Each thread has its own set of signals and the meaning of a signal is thread dependent.

    Messages

    The backbone of Fenix is messages. "interprocess"-synchronization and communication are performed by messages. A message in fenix consists of a number of 32-bit registers.

    Ports

    A message is sent to a port that the recieving thread have created and is listening to. This is very similar to mach. The ability to bundle ports into sets that mach have is not used in Fenix. All ports are referenced by handles, which is the same as capabilites in mach, similar to filehandles. The handles are stored in the memoryspace and are thus shared by all threads that are executing in that memoryspace.

    Monitors and semaphores

    Ordinary semaphores and monitors is used to syncronize threads running in the same adressspace. There is also a possibility to make monitors and semaphores global or shared so that threads from many adressspaces can use and share them.

    Shared libraries

    On TOS/MiNT shared libraries has been a sort of mythical creature. Many have wondered if it is possible to use them others has just ignored the teorethical questions and implemented different schemes. Fenix has support for shared libraries in the kernel. OS-calls is meant to be library calls that can if necesserily post a message for a server if the call cannot return immediately.

    What can the nanokernel do?

    It is vital that the nanokernel is small and has all the necessarily mechanisms to handle context switching,paging, syncronization, basic memory handling, shared library and message passing. I believe that this is sufficient:

  • Context switching: Switch thread and or memoryspace and handle aging of processes, that is lowering the priority of threads that consumes more than the allocated timeslice.
  • Paging: Swap pages to and from the backing store, ie hard disk, and updating the MMU page trees.
  • Thread signal:Handle waiting for thread signals, allocation and deallocation as well as sending signals to a thread.
  • Messages: Uppdating port structures and blocking the calling/recieving threads if necessarily.
  • Syncronization: Handling of monitors and semaphores. Also handles sleeping and waiting threads.
  • Memory: Allocation and deallocation blocks, ie pages, of memory. Handles many different memory kind, ie st,tt,shared and global ram.
  • Shared Libraries: Swapping of dynamically linked library calls and libraries.
  • All other activities are handled by servers which have more or less access to the memory of the microkernel. The communication to these servers are usually handled by messages or by shared library calls.

    What does the nanokernel look like?

    The nanokernel is very small about 4-8k of code written entirely in assembler for size and speed reasons. The amount of resident, ie non virtual, memory is also small about 8k. The nanokernel consists of four parts.

  • The pager which handles virtual memory.
  • The swapper which is the controller of the swap hard disk or file.
  • The syncronizer which handlles thread syncronizing and timequeue.
  • The librarian which handles swapping of library routines.
  • Only the pager and the swapper needs to be threads and even these do not need to be true threads and communication can be faster because the threads are in the nanokernel. The nanokernel must be assembled to the computer that it is running upon since contexts are saved differently on different processors. On a 68000 for instance there is no need for the pager and the swapper.

    Internals

    Here are some internals for spec freaks:

  • Threads:
    1. maximum number of threads in a system: unlimited
    2. number of priorityqueues:32
    3. number of prioritylevels: about 64000
  • Messages:
    1. maximum number of ports per memoryspace: unlimited
    2. more than 8000 messages sent and recieved per second including contextswitching on a 8MHZ 68000
  • Memory:
    1. page size: 4k
    2. maximum memory allocated to a memoryspace: about the same as maximal virtual memoryspace of the computer.

    Documentation

    Developer documentation is currently being written since I believe that the current kernel is the final one.

    Where is it?

    I foolishly said that the kernel would be finished in late April 96. It actually was but then I also began looking into integrating support for Java and Inferno in the kernel. I soon realised that incoperating these features meant that the kernel needed to be completely rewritten. There have also been some more revisions of the kernel after that depending on various good features that I wanted to include. The current revision is the 7th one and is much more modular than the previous ones. It is also even faster than before.

    The future

    The kernel have been delayed a lot due to many restatements of goals and rewrites that followed. The kernel is now finally finished. However, I will not make it completely free until I know it's really stable. It is not unstable but I want to implement more of the core system so I can test the kernel with real programs. Also the kernel is being ported to PPC for the Tempest accellerator.

    Here are a list of servers and libraries:

  • Resource manager (server): handles everything about threads,memory,devices, libraries and filesystems that the nanokernel doesn't handle.
  • Filesystem library/servers: handle files on devices. Currently supported file systems are VFAT/FAT32/FAT16, Minix and ext2fs.
  • Network library/server: handles everything about networks. This server is very much like a filesystem.
  • VDI library/server: handles lowlevel screen usage. The VDI is nearly finished and will be shipped with the Eclipse PCI adaptor.
  • AES library/server: handles aes-calls. The AES is now under development
  • Application library/server: makes an easy OO-interface based on FOOPY that an application can use. The class tree is loosely based on OpenSTEP.
  • Goodies

    Goodies that can be implemented into Fenix are memorymapped files, dynamic linking and... If something is needed write a server!

    Notes to Fenix implementors

    Portability

    Fenix should be and must be highly portable. That is however no reason to do things slow. Things that must be really fast must be coded in assembler. We must make the common case fast a la RISC processors. Fenix is meant to be a fast and slick OS that is small, powerful and easy to extend by new servers and libraries. I think that we must face the fact that we must port fenix to PPC or another processor about the same time as it is beginning to work on the 680x0. We must bear this in mind but also make good solutions to problems. We cannot rely on more powerful processors with every new version like microsoft.

    Implementation language

    Fenix is currently implemented in C and assembler. Some minor parts are written in C++. There is currently no competition to these languages.

    Suggestions Comments Flames???

    Mail me at the adress below!

    Sven Karlsson
    Istari Software
    email:sven@it.lth.se