Working on toy OS...

This forums is for OS project announcements including project openings, new releases, update notices, test requests, and job openings (both paying and volunteer).
Post Reply
User avatar
ababo
Member
Member
Posts: 27
Joined: Thu Jun 13, 2013 8:20 am
Location: Ukraine

Working on toy OS...

Post by ababo »

Hi guys,

Here is my current hobby project (https://github.com/ababo/toy):

Simple OS-like program for x86-64, which dreams to become a real OS.

Design vision (to be implemented):
1. Single address space OS. All available external memory is mapped into it.
2. Persistent applications. They not only survive reboot, but also can be
transferred to another machine (with a same architecture) and resumed there.
3. Virtual machine for memory protection and security.

Already implemented:
1. Multiboot specification support (for GRUB2 or patched GRUB).
2. Textual VGA-mode (16 colors, limited kprintf).
3. CPU topology detection (sockets, cores, threads) for Intel and AMD CPUs.
4. Convenient page mapping interface.
5. Support of interrupts written in C.
6. Simple preemptive scheduler with SMP support.
7. Synchronization primitives: spinlock, mutex.

Supported compilers:
1. GCC
2. CLang

Build environment:
1. Linux (known to work on recent Ubuntu).
User avatar
BMW
Member
Member
Posts: 286
Joined: Mon Nov 05, 2012 8:31 pm
Location: New Zealand

Re: Working on toy OS...

Post by BMW »

I really like the persistent applications idea....
Currently developing Lithium OS (LiOS).

Recursive paging saves lives.
"I want to change the world, but they won't give me the source code."
User avatar
iansjack
Member
Member
Posts: 4685
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: Working on toy OS...

Post by iansjack »

BMW wrote:I really like the persistent applications idea....
It's good to see someone taking inspiration from Windows 8 rather than the normal mindless criticism.

1. Is the basic idea in OS/400.
2. Is one of the better features of Windows 8.
3. I'm not sure what you mean by this. Most modern OSs already have memory protection and security ensured by the paging mechanism.
User avatar
ababo
Member
Member
Posts: 27
Joined: Thu Jun 13, 2013 8:20 am
Location: Ukraine

Re: Working on toy OS...

Post by ababo »

1. I think the idea is taken from Pantom PS (http://en.wikipedia.org/wiki/Phantom_OS).
2. Windows 8, iOS, Android don't provide true persistence because it's not transparent for their applications (they need to manually save and restore states by events).
3. Yes, but the approach is a little bit different. You have only a single address space for all applications. Read about Microsoft Singularity OS.
User avatar
iansjack
Member
Member
Posts: 4685
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: Working on toy OS...

Post by iansjack »

1. OS/400 (and its earlier versions) precede this Russian OS by many decades. Reading thast Wiki entry, I would guess that the designers were inspired by OS/400 as it seems to borrow its features.
2. It is true that applications (but not the user) have to decide that they want to persist in Windows 8. This would be an essential (IMO) in any secure OS. Unhindered persistence would not be a good idea.
3. Paging gives each application its own address space unreachable by other applications. This is a good thing.
User avatar
sortie
Member
Member
Posts: 931
Joined: Wed Mar 21, 2012 3:01 pm
Libera.chat IRC: sortie

Re: Working on toy OS...

Post by sortie »

You can only have a single address space securely if 1) you can statically prove the problems never do any invalid memory accesses (you cannot trap such accesses because you are using a single address space 2) you have some mechanism for pre-empting/relocating program's memory areas (such as moving them around and swapping them to disk when the address space fills out) or things would get too fragmented.

You cannot do the first in a language as such as C due to the undecidable nature of such programming languages, unless you severely want to restrict the programming language. Additionally, the relocation part is also very impractical in C because you have to know what memory are pointers. You know that some memory are pointers thanks to debugging symbols, but this get much harder because you can store a pointer by casting it to an integer, xor'ing it with some magic, and then to read it, you xor it with the magic value and cast to a pointer. You can work around the need to relocate programs if you have your virtual address space map memory the size of main memory and the secondary storage. You can then just simply swap out pages of the global shared address space and there is no need to relocate programs. It may still be needed if a program allocates a very big buffer, which leads us back to the problems caused by segmentation and solved by paging (which is wonderful!).

My point is that you can do this if you write your own compiler and do all the static checking to verify program behaviour. This is a much bigger task than a "toy OS" and nothing in your original design suggests you want to do this. Note how paging is the standard method of memory protection and while it can be confusing at first, it solves a lot of problems very well. If you consider a single address space because you are lazy, then you get what you deserve: Additional work.
User avatar
ababo
Member
Member
Posts: 27
Joined: Thu Jun 13, 2013 8:20 am
Location: Ukraine

Re: Working on toy OS...

Post by ababo »

sortie wrote:You can only have a single address space securely if 1) you can statically prove the problems never do any invalid memory accesses (you cannot trap such accesses because you are using a single address space 2) you have some mechanism for pre-empting/relocating program's memory areas (such as moving them around and swapping them to disk when the address space fills out) or things would get too fragmented.
That's why I need a virtual machine on top of my system code. All user-level modules should not contain a native code.
sortie wrote:You cannot do the first in a language as such as C due to the undecidable nature of such programming languages, unless you severely want to restrict the programming language.
Of course no C API will be exposed to user-level applications. I would like to employ some ad hoc dialect of LISP as user-level programming language (I have some vision of it but still no prototype).
Post Reply