OSDev.org

I wasnt sure where to post this idea and this seemed like the most open forum on the board so I decided to place it here.

This is an idea for an OS. I've been wondering what my OS should look like for a while now and I came up with tenative plans for Goodsoup OS which will be a windows clone with a touch of linux style but I wanted something original to work on first. Then today in my half asleep daze I came up with "Recursive OS."

Recusive OS:

Basic Idea:
Idealy everything will be able to copy itself within itself. A window can be created inside another window using a single command. However the window is limited to the properties (excluding size and position) of its father so they can use 90% of the same code and ram. No child can exceed its parent and must have the same properties as its parent as much as feasibly possible. Allowing for ease of development, no need to register each and every window anymore just call for another.

Kernel:
Micro, keep it as small as possible so by recursivly implementing it you dont eat up half your resources.

File System:
Windows Clone

Look:
Probably going to clone the look of windows. However your desktop will be a closeable and resizeable window. The task bar will sit at the bottom of the screen and will probably be the only thing that is not recursive along with the mouse and keyboard who will remain independent of the window system as without them you would be pretty much screwed. Each desktop can implement different resolutions and color schemes and all the inheriting windows will follow suit. A program can implement a desktop if it chooses.

C&C? Details I forgot?

You just describe the look of your operating system. You don't describe its internal design. Such a look can also be archived using windows or linux.

Kernel:
Micro, keep it as small as possible so by recursivly implementing it you dont eat up half your resources.

What exactly does "recursively implementing" mean in the context of your kernel?

@Korona
The internal design is recursiveness. The ability to clone something ontop of itself is the only difference between it and another OS. The code will probably contain alot of recursive calls to keep with the style.

@JamesM
It would mean you implement a kernel that answers to its parent kernel. System resources can be dedicated solely to one or the other kernel as long as the parent owns the resource.

Lets say you have a set of hardware that allows you to build a terminal, with this idea it would only require a second moniter, keyboard and a mouse (and of course a program that implements a kernel). You can then implement a secondary kernel that the terminal user acts upon. It will handle everything it can and pass onto its parent what it cannot. You can even remove features, as long as it keeps within the bounds of its parent, so if all the calls that have to be passed on are disabled the main system can remain isolated of the terminal.

chezzestix wrote:@Korona
The internal design is recursiveness. The ability to clone something ontop of itself is the only difference between it and another OS. The code will probably contain alot of recursive calls to keep with the style.

@JamesM
It would mean you implement a kernel that answers to its parent kernel. System resources can be dedicated solely to one or the other kernel as long as the parent owns the resource.

Lets say you have a set of hardware that allows you to build a terminal, with this idea it would only require a second moniter, keyboard and a mouse (and of course a program that implements a kernel). You can then implement a secondary kernel that the terminal user acts upon. It will handle everything it can and pass onto its parent what it cannot. You can even remove features, as long as it keeps within the bounds of its parent, so if all the calls that have to be passed on are disabled the main system can remain isolated of the terminal.

Hi,

So what handles the scheduling of processes? Does the "parent" kernel schedule kernels, and "leaf" kernels schedule processes?

You can't really call that a kernel any more. The set theory definition of a "kernel" relates to the subset A of a group B where there are mappings from C (C = U - A) to A, but no mappings ever from A to C. (Where U is of course the universal set).

This behaviour matches that as described in words - "The kernel is the set of functions that relies on nothing outside it, but which everything relies on".

By having your nested kernel idea, you're breaking that definition, so the line becomes very blurry as to "what actually is a kernel, in your idea?"

Cheers,

James

This behaviour matches that as described in words - "The kernel is the set of functions that relies on nothing outside it, but which everything relies on".

I may be using the word kernel very loosly but I still do use it because its keeping track of resources for programs as a kernel would and thats what its modeled after. The more I look at the theory they kinda just act as gates... really cool gates that allow more than one user on a computer without special hardware.

So what handles the scheduling of processes? Does the "parent" kernel schedule kernels, and "leaf" kernels schedule processes?

If the child, or "leaf", kernel is given sole usage of a core then it will schedul the processes. Otherwise it will be told it does not have permission to do that and will be passed onto the parenting kernels until it can be handled. So these are best implemented on a multi core system (in which case, coupled with disabling everything that has to be passed on, they come close to being an acutal kernel).

I'm not too sure how this is different from any other os? What's the purpose of having multiple "kernels"? It doesn't add any multi-user benefit. Linux is a multi user system(and a damn good one at that) and it only has one kernel. Also, most windowing systems have the concept of a hierarchy of windows. For example in the X window system, every window has a parent(except the desktop). Top level windows are actually children of the desktop window.

Also, I'm not too sure that you're correctly using the word recursive. You're os sounds more like some sort of massively hierarchal system.

it actually sounds like you are wanting to have one core (extremely micro) kernel which will in turn manage a cluster of application monitoring/managing daemons. Those daemons would still in turn rely on the kernel base code to even become daemons in the first place. Also, the only real way I could see seperate kernels being implemented would be if one kernel (boot kernel) loaded and transfered to another completely self contained kernel to manage other processes, but that would be bulky.

I get pimples when someone picks up a screwdriver, says "this is one fine tool" and sets out to solve whatever problem he encounters using that screwdriver, even if the "problem" is a nail...

Recursiveness is a means, not an end...

I voted terrible.

One thing you might want to look into, however (and it might well interest you) is the use of an object-oriented design using inheritance.

EDIT: Explanation is that I don't see the use of it. It's just extra code to be written.

@01000101
Yea your right it does sound like a massive hierarchical system but Recursive OS sounded better than Hierarchial OS.

@iammisc
Has anyone tried it? If not, then how do you know its not twice as powerful as multi usering with one kernel?

@Solar
Excuse me for mistaking hobby OS making for a platform to possibly one day fix what bugs us most about the current big name OSes.

and BTW even a screwdriver can handle a nail applied correctly. I get your sentiment though.

@Yayyak
I know all about OOD having programmed in Java, Visual C++ and Visual Basic and your opinion is duly noted.

General Message:
Idea scrapped, 10/11 (at posting time) people voted meh or below (I voted meh) so obviously recursive isnt an ends however I do like some of the ideas that got fleshed out in this little brain excercise and they will possibly show up later on. Dispite the terrible acceptance of hierarching kernels I think I'm going to hold onto the idea...

Good to see you took it in good mood.

I can't really distinguish between the standards I apply to hobby projects and the ones I apply to professional work. If anything, my private standards are even higher. I know this alienates people sometimes, but I can't help it - sorry.

maybe I will experiment with this design as well, but I honestly don't see it going anywhere important... or in a speedy manner for that matter. but never the less, it is a unique design and worth giving it a go, cuz who knows.

Has anyone tried it? If not, then how do you know its not twice as powerful as multi usering with one kernel?

Of course no one's tried it. However, what I was trying to say(maybe you took it the wrong way) is that from your own description, all the advantages that you claim to have over other OS's is something that other OS's do actually have in reality.

For example you said

The more I look at the theory they kinda just act as gates... really cool gates that allow more than one user on a computer without special hardware.

Which is basically what most unices can do. They allow multiple terminals. However, your OS cannot take away the need for special hardware. If you do not have enough physical space to plug in a monitor, you're going to need special hardware regardless of whether or not you have a multi-user environment.

Why don't you explain to us how your idea has any advantage over other kernels. From your talk of kernels within kernels, it seems to me you'd be better off by writing a hypervisor.

The special hardware I was referring to is the fact that in windows to seperate a keyboard from the kernel you have to have a PCI adapter card. With an agent, my name for a sub kernel I think I've decided, you can seperate resources from the kernel in a soft manner.

My idea may not have any advantages over a single kernel OS but the advantage is the ability to do this:

Lets say sound card 1 is hooked up to your desk speakers and sound card two is hooked up to sound card 2 is hooked up to your living room stereo. Normally you have to dance around and hold your mouth just right to get windows to even think about doing what I'm going to do in just 4 steps.

1) Set up an agent and assign it a free core and sound card 2
2) Remove all the agents permissions except user input and sound output
3) Run a media player on Agent 1
4) Continue about your business

Never will any of your desktop audio come out of your living room stereo and the music will never come out of your desktop speakers. Most times step 1 and 2 will already be done so after you do this once its really a single step process. Furthermore the media player is isolated from the rest of the system and the system from it.

And something undoable without special hardware on windows:

1) Set up an agent with a core, sound device, keyboard, mouse, video chipset and virtual NIC
2) Remove any unneccisary permissions
3) Network virtual NIC with the virtual NIC on the kernel
(Share interenet with the vNIC network if needed)
4) Start game on Agent 1 and kernel
5) Game with your friend as if on a console with the comfortability of a PC
6) When done de-initialize Agent 1 if need be

Your friend might be a little ticked you gave him the chipset but at the profit of not having to bring over his computer he wont complain for too long. I use an extra core in both these examples but even if you dont have one the Agent will just submit all its processing needs to the Kernel. With no real processing done upon the commands there will be minimal bottlenecking (although there will inveitably be some).