OSDev.org

Maybe a thread for this exists, but if so I haven't found it.

So, OS Devs, what makes your OS special?

mine has all the code in header files and can run basic
why did I get into OSDev?!

For me, it is simply this: There are many others like it, but this one is mine.

Mine is the ultimate simplification: it doesn't exist! But nullplan has the best answer.

I have UI ideas, but they don't really need to be implemented as an OS. I have other curious ideas for OS internals, but it's hard to figure out all the ideas together. I intend to implement a bootable Forth and try the ideas out in that. Forth is flexible enough.

1, Its not POSIX and never will be.
2. The whole OS is built around the actor model. All communication between processes is through an IPC message protocol. Similar but different to 9p.
3, All programs are daemons that each speaks to the outside world through the same IPC mechanism. This makes it easier to do asynchronous programs without having to do signals.
4. No dynamic memory management so running out of memory is never an issue, only having enough is.

Among other things.

The last point (no allocation) is interesting. How do you achieve that? Does it already work or is this only a concept?

Jezze wrote:3, All programs are daemons that each speaks to the outside world through the same IPC mechanism. This makes it easier to do asynchronous programs without having to do signals.
4. No dynamic memory management so running out of memory is never an issue, only having enough is.

So do you load all programs (demons) at once when the system boots up? What if I want to execute multiple instances of the same program, wouldn't memory be dynamically allocated for the new instances in that case?

Hi!

Korona wrote:The last point (no allocation) is interesting. How do you achieve that? Does it already work or is this only a concept?

iocoder wrote:So do you load all programs (demons) at once when the system boots up? What if I want to execute multiple instances of the same program, wouldn't memory be dynamically allocated for the new instances in that case?

This is more than a concept by this point I think, it's more of a working prototype or something. In the kernel I have allocated a fixed amount of memory for each task and I have a fixed number of tasks (both can only be set during compile-time). Something like 1MB * 128 tasks or something like that which would take up 128MB of RAM. The programs themselves can only use their 1MB for code and data and can not allocate any more. So the only thing memory-wise that could fail is that you could run out of free tasks but as of right now the OS doesn't use a fraction of those 128 slots, more like 4 or something. Yes you can have multiple instances of the same program. Interestingly, some programs (daemons) can actually run as a single instance for example a program like "ls" and all invocations of ls would just reuse the already running one. I don't have it like that right now but I could and I have tried it just quickly but I don't know if it's a good idea. Also, starting all daemons at boot could potentially work as well but that's not how it works right now. I will have to think about it more, it's not a bad idea.

EDIT: I checked because I didn't quite remember, the actual size I use right now by default is (512K for code and data + 32K for stack) * 128 tasks.

EDIT 2: This is the hello world program, just so you can see what a userspace program looks like. Syntax/naming of stuff is subject to change. Basically it starts by setting up a channel and a bunch of callbacks for when it receives different types of messages on that channel. The badly named EMPTY message is what will be sent to this program when it is called with no inputs which will trigger the onempty handler which in turn will reply with a DATA message containing the text "Hello World!" to the source that sent the EMPTY message. Anyone can go in and hijack this reply by sending a REDIRECT message to this program telling it to forward any DATA message to some other source. If it receives the DONE message it will close the channel which will make the program quit.

Interesting. Thanks for explaining, Jezze.

Jezze wrote:Interestingly, some programs (daemons) can actually run as a single instance for example a program like "ls" and all invocations of ls would just reuse the already running one. I don't have it like that right now but I could and I have tried it just quickly but I don't know if it's a good idea.

I think it is a good idea based on your design philosophy. You could keep frequently-used programs (like ls) running in memory, and whenever you any other program needs something from ls, the action could be performed using one of those events. The program (e.g. ls) will be more like a 'daemon' in that case, and this relates well to what you have described.

Interesting! For a while, I've had at the back of my mind, "What if all programs worked like awk?" but never explored it. I do think the function invocations are rather long, but that could be eased with typedef struct channel channel; typedef unsigned int uint;.

I think the main issue is that it is not a clone of Linux, not built with GCC and not naturally posix-compliant. The main thing is that all the major code (except ACPI and the FreeFont driver) are built from ground up.

Another thing is that it runs on a few thousand real installations.

Mine is specialized for network and disk being a headless server

I'm barely past the hello world phase, but some of the unique or rare things among my design goals are pervasive ground-up superpages and load-balancing process migration clustering with distributed shared memory, IPC, and filesystem. Navarro et al published on superpaging but no OS's are really shipping it. Milojičić published on process migration for Mach, which already had distributed shared memory, IPC, and fs, but it didn't really survive outside his experiment. I'm foggy on how much of the Mach feature set is able to be resuscitated from available source code. So they're not fully novel, but actively maintained implementations of them would be worthwhile.

I have other aggressive design goals, but I believe the rest are shipping in actively-maintained commercial operating systems.

currently my os is just a "hello world bootloader" but i have a design in my mind. i want to make it as simple as possible. my focus is on its api, i would create a new api. i want to create something that doesn't exist before. it's too hard and takes a lot of time and also needs some more ideas. i have a lot of example runtimes and frameworks in my projects directory that all of them are incomplete. my next framework will run on my own os.

my goal was also to make a simple OS, it must have been 8 years since I passed the stage of bootable helloworld and that it is not as simple as I hoped. I managed to do something that works pretty well without using virtual memory and paging so overall the goal is achieved, I still need to improve some points and finish others..

and for the "special features" there are strictly none (sorry) in order to make it as simple as possible I dont implement a GUI with several windows, each task uses the whole screen (one screen per task but we only display one at a time, and most of the time in a simple emulated text mode) I am not from the world of pure IT and there are still a lot of things that are unknown to me (for example superpagination I had never heard of it before today)