OSDev.org

I have made some "typical" Hobby Operating systems, (with paging, usermode, ELF file loading, Higher-Half, FAT32 support and other stuff..) But now I am thinking of a whole new design:
This time, my OS wll not use pagng, nor user mode, but it should be able to load so-called user mode programs. Those prgrams would not be able to tamper with kernel memory or othe programs' resources. The trick would be that the kernel would be running a super simple VM internally. On request, that VM would load user applications. The instructions would be executed by the kernel, not the CPU. (the kernel will do what the application instructs it to do.) because the process would only be allowed to use as much resources as permitted by the kernel, the whole system should look very similar to other typical Unix clones.
The VM is almost ready. I intend to write programs for it in it's own version of assembly.

Am I doing the right thing, or this is simply a waste of time ?? Suggestions are welcome.

That's no operating system, that's a bare metal hypervisor.

What are the advantages over supervision by cpu?

snasim2002 wrote:The instructions would be executed by the kernel, not the CPU.

How come? Is the CPU gonna be idle / in power-saving mode?

snasim2002 wrote:Am I doing the right thing, or this is simply a waste of time ??

Are you having an XY problem?

snasim2002 wrote:This time, my OS wll not use pagng

Big mistake. Why ignore such a useful protection and virualization mechanism? What do you expect to gain by not supporting paging?

Otherwise you just seem to be describing a fairly standard OS model with an (unnecessary and inefficient) extra layer of CPU virtualization inserted. What's the point of this (other than to provide a less efficient implementation of the memory protection that you have thrown away by not using the processors natural MMU)?

Hi,

Hellbender wrote:That's no operating system, that's a bare metal hypervisor.

I think snasim2002 means something more like a SASOS running a managed language (sort of like Singularity, but with interpreted byte-code rather than compiled byte-code).


Cheers,

Brendan

snasim2002 wrote:Am I doing the right thing, or this is simply a waste of time ?? Suggestions are welcome.

Yes, you are doing just the thing you want, so it should be right for you.

But may be you are asking about what is right thing for us?

As others have already mentioned, this is just a bare-metal hypervisor, and it really isn't a new design. It's been done before, and it's going to have much lower performance than your real hardware can manage.
Oh, and paging is something very valuable; developing a bare-metal hypervisor is not a reason to abandon paging support.

I agree paging is incredibly usefull.. I have used it extensively in my previous kernels, but, as I mentioned, this time I don't want something "usefull", but I want something "new", even if it't inefficient. My ultimate goal for this project is to get an OS that is completely different from the other OSes I built.

Personally I wouldn't pursue novelty just for its own sake. But it's your time, your OS, so you do what you like. If you want to produce an OS which avoids using the "mov" instruction, or the SI and DI registers, anywhere those would be valid choices too.

The only thing that puzzles me is why you are asking here if it's a good idea. What's that got to do with anything?

Actually, this is less like a hypervisor than an exokernel; but since those are basically different perspectives on the same technology (where the difference amounts to whether you see each VM running a client operating system, or just a single process with shared libraries for services), it comes down to how you look at it, I guess. It's the sort of thing that could get you arguing over definitions for weeks without resolution.

snasim2002 wrote:Am I doing the right thing, or this is simply a waste of time ?? Suggestions are welcome.

This very generic description sounds fine in general (well, except dropping paging). A lot depends on the design of VM and the language/command set it executes. Maybe you can tell a bit more about them?

For performance reasons, you may want to use JIT- or AOT-compilation and actually execute native machine code, but limiting it to the code generated by the kernel from the verified VM code.

In 64bits , you will be forced to use paging.
having a single address space will not protect you against TLB misses, provided that you will end up having many virtual addresses active at the same time , and the fact that the TLB is small.
If you stay in 32 bits with a single address space, you will have to implement software pagination, because you will want to swap out " not recently used" ( but reachable ) objects .

What kind of benefits no pagination will give you ?