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).
Working on toy OS...
Re: Working on toy OS...
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."
Recursive paging saves lives.
"I want to change the world, but they won't give me the source code."
Re: Working on toy OS...
It's good to see someone taking inspiration from Windows 8 rather than the normal mindless criticism.BMW wrote:I really like the persistent applications idea....
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.
Re: Working on toy OS...
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.
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.
Re: Working on toy OS...
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.
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.
Re: Working on toy OS...
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.
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.
Re: Working on toy OS...
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 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.
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).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.