It's been a while since I've been updating my blogwith posts, and for that I'm truely sorry! The reason is my involvement in aresearch project where we are trying to design a new operating system for thefuture!

The common operating systems of today are based ontechnology developed many years ago when topics as scalability, security andpower consumption was not a major concern in computing, like it is today.

This is the primary motivation for developing a newoperating system from the bottom with the aforementioned issues.taken intoaccount from the start.This leads to the FenixOS which is a research operatingsystem, which is aimed at the hardware specifications of computers today – thatbe Desktop, Laptop, Notebooks, and Embedded devices (Smartphones etc.)-  But even more at fact that computer systems ofthe future will contain even more CPU's than currently computers. This fact andthe fact that current operating systems all have a creation date ranging fromthe 70's through the 90's where uni-core systems where common, has made it duetime to refactor  the architecture ofoperating systems. FenixOS supports an arbitrary number of CPU's and focuses onstability, security and the need for less power usage. It is based onmicrokernel architecture to enhance stability issues, and enforces securitythrough access control lists - among others. A complete rewrite of theunderlying system structure is made in C++, to clean up the disorderlystructure seen in many current operating systems. Although everything is newand cleaned up, FenixOS is still set to be compatible with current applicationsrunning on current operating systems, this meaning that applications that runon Linux, MacOS and Windows is aimed to be able to run on FenixOS. FenixOS doesdistinct itself  from Linux by eg. Havingseparate notions of threads and processes.

How this will be achieved is still on the researchstage, but initial ideas are on the drawing board. The easiest approach toobtaining compatibility with the Unix variations of operating systems, is toport the EGLIBC library to the FenixOS platform, while off course stillupholding the POSIX’s standard. EGLIBC (embedded GLIBC) is a variant of the GNU C Library (GLIBC). GLIBCis the C library used by most Linux kernel based operating systems.

We had to start off there-designing of the operating system structure, by considering which systemcalls are necessary for an operating system to compile itself. In this phase wehad to – in order to maintain compatibility with current operating systems –examine how current systems conduct their system calls, and thoroughly considerthe impact on security, stability and power consumption. We examined Linux,MacOS, Solaris, FreeBSD, Windows, and Singularity,paying especially attention to the thoughts and design of the researchoperating system Singularity, to see how these ideas would be suitable inFenixOS, without breaking the POSIX standard and the compatibility with otheroperating systems. The one major problem of looking at the Singularity researchproject is that Singularity uses managed code language to enforce securitybetween processes (among others) called SIPS. FenixOS is implemented in C++programming language, and therefore cannot utilize the security of managedcode.  We have reasoned that thefollowing system calls would be necessary for a basic new operating system:  

For self compiling:

Fork(), Execve(), Exit(), CreateThread(),ExitThread(), Wait(), Futex(),

For  file operations:

Open(), Close(), Read(), Write(),Stat(), Seek(), Link(), Unlink(), Ioctl(),

Message passing:

Send(), Receive(),

Memory management:

Malloc(), Free()

I will not be going through allthe systemcalls here, as this is just an introduction, but I can give a glanceof what we did with wait() systemcall.

By looking through source codeson the GLIBC we found that there are different versions of the wait() systemcall, all with different functionality, and by further examining thedocumentation on the different libraries, GLIBC, EGLIBC and such, we found thatthey all could be combined into one single system call, without breakingcompatibility with existing operating systems. This is done by keeping theexisting functions – wait(), waitpid(), wait3(), waitid() and wait4(), buthaving all of the aforementioned functions calling our newly created do_waitid().

It appears that over time newwait() calls with new features has been invented and added to the differentUNIX like operating systems (Linux, BSD, Mac OS, etc.) but not all of the oldwait() calls has been removed. The most powerful of the wait system calls arecalled waitid(), this system call takes a total of four parameters and withthose it can replace the old system calls wait() and waitpid(). If we add afifth parameter, the waitid() system call can also replace wait3() and wait4().In our EGLIBC code we call this system call with five arguments do_waitid(). Becauseof this we decided to just implement one wait system call in the FenixOS kernelwhich will just be called wait() and act similar to the described waitid()call. It will then be up to the C library to map the four other system calls tothis one existing in the kernel. The system call interface looks as follows:

pid_twaitid(idtype_t idtype, id_t id,              siginfo_t* infop, int options, struct              rusage*usage)

The first argument idtype can hold 3 different values whichindicates how the second argument idshould be interpreted. If idtypeholds the value P_PID then it meanswait for the child process with the process id that matches the second argumentid. If the value is P_PGID then it means wait for any childprocess which has a process group id that matches id. Finally if idtype is P_ALL then id is ignored and there will be waited for any child process. Thethird argument is a pointer to a structure which holds information about howthe child process stopped execution. With the fourth argument options it is possible to tell when thesystem call should return. It could return when the child exits of course butalso if the child changes from one state to another, for example if the childis blocked or when it wakes up. The last argument usage is the one added to support wait3() and wait4() system callswhich are the only ones using this type of argument. The structure holdsinformation about which resources the child held and which therefore should beavailable. The trickiest part of mapping the four system calls to waitid() isthat only waitid() is using the aforementioned structure siginfo which holds information about how the child terminated. Theother four system calls uses a pointer to an integer to get information abouthow the child process terminated. EGLIBC has some build in macros that userapplications can use for interpreting this status code. So the EGLIBC code hasto translate from the siginfostructure to the status code. Luckily EGLIBC also has some build in macros forcreating these status codes which simplifies the translation part a bit (Can befound in libc/bits/waitstatus.h). Another thing we had to be aware ofwhen mapping the system calls was that not all options in the options argument could be used for allsystem calls. Therefore we added error checking for this in the EGLIBC code andreturned error code EINVAL (Error:Illegal argument) before the kernel would be bothered with the system call. As wementioned earlier we have created two different waitid() system calls in theEGLIBC code. One takes the five arguments mentioned in this section and doesthe actual call down the the FenixOS kernel. This function is calleddo_waitid(). The other is called waitid() and takes the four argumentsoriginally intended for waitid() and maps those to do_waitid() (Leaving usage with value NULL).The latter is meant for user applications wishing to call waitid(). Thefirst should only be used by the EGLIBC code for mapping the other systemcalls. By creating this mapping between the wait system calls in the EGLIBCcode we cut down the number of wait system calls in the kernel to one. Butstill we are able to support already existing applications which may make useof the older wait system calls.

This off course just give a smallinsight in to a very big subject, where we to this date haven’t been able totest our system yet. As stated earlier, it’s a research system, and the designis a subject to change…. J