WHAT AN OPERATING SYSTEM SHOULD BE (IN OUR SENSE)

The great question
Traditionnaly, the requirements of an operating system are defined to a very high level: - shall manage files, - shall browse the web - shall be nice in a user point of view, - shall do this or do that, Linux does, Windows does also. Our purpose is not to redo the hugh work that has been done but only to develop simple but great things. Other high level stuff will come later.

We could say that our requirements are quite basic and are illustrated in the following diagrams:

X86os Use Cases

Some important conceptual "bugs"
As you can see, our goals are quite reasonable because they are limited to some few important basic concepts. And because we are reasonable, the first thing we notice is the surprising limitation of some well know operating system architectures:

- Memory Allocation "bug": In POSIX like operating systems there is no standard way of dissociating physical memory from virtual memory. If you do a sbrk(2) for example, the system will allocate both physical and virtual memory pages for you. There are too many constraints on memory access at the processor level (segments, ...) for a good operating to ignore this requirement.

Memory Allocation Use Cases Differences

Anyway it is possible to dissociate virtual memory from physical memory but you need to write a specific driver with proprietary ioctl calls.

Posix Memory Allocation

Since calls are indirected, it induces a lot of error management in the kernel side. In LSE/OS, physical memory and virtual memory are natively dissociated, errors are managed at the task level:

LSE/OS Memory Allocation

Furthermore if you want to share this memory area then you have to deal with complex "shm" system calls, ..., under LSE/OS, sharing physical memory is just a basic use case of the memory model (look into the LSE/OS memory management section). With this technical choice, managing memory becomes simpler and powerful for all use cases.

- Signal stack "bug": On traditional unix systems, when sigaltstack() isn't used, the system allocates a stack for signal handlers: what happen if there isn't enough memory in the system at this moment? This is a case that isn't clearly managed under Unix. On LSE/OS, it is mandatory to provide a pre-allocated stack pointer to the signal handler.

Additional "modern" requirements
In order to fulfill modern requirements our operating system should of course:

Dissociate tasks from address spaces: For creating real "clones" but also forked like processes.

Guarantee security: We use the uid/gid concept from Un*x. Of course, none of the system calls of the operating system could be flawed to give root access!.

Which services do we really need?
Finally we need only the following limited services to perform all the complex operations:

Operating System Use Cases