Plan 12 - a kernel-less scheduler-less operating system (discussion/feedback)

[vantheman]

Hello everyone! Thanks for reading this post!

As you can most likely tell, this is my second post here.
I am trying to get technical feedback and suggestions on this operating system I
am working on known as Plan 12 (no, the subject was not a lie).

Plan 12 is a fully kernel-less and scheduler-less operating system designed to unify and simplify the interface drastically.
Essentially, all processes are boot-kept by files. Said processes communicate through signal and buffer files. Scheduling is performed via fully co-operative primitives expanded at compile-time through inline macros. Each 'scheduler' is bound to one file system, which is bound to one physical or logical execution unit. Hardware is managed by a group of processes providing hardware I/O via the process communication primitives.

Again, this is a very brief and high-level overview of the system. The full documentation can be found at http://git.community.i2p/vantheman/plan12 - 'general' being the specification (known as Plan 12) and 'vp12' being the reference implementation.
(However, if you cannot use i2p, there is a mirror over the clearnet at https://codeberg.org/vantheman/plan12)

I post this asking for feedback on the system and it's overall design. This is my first operating system and I am learning this while still reading the Intel Architecture manuals.

(I now realise this should have probably been posted here insted of the 'os development')

Links:
New master: http://plan12os.org
Documentation/source
Master : http://git.community.i2p/vantheman/plan12
Slave-codeberg : https://codeberg.org/vantheman/plan12
Feedback/discussion
https://forum.osdev.org/viewtopic.php?p=353982#p353982
https://forum.osdev.org/viewtopic.php?p=353971#p353971
https://dev.to/vantheman/plan-12-a-full ... ystem-3foa

[nullplan]

Plan 12 is a fully kernel-less and scheduler-less operating system designed to unify and simplify the interface drastically.

Kernel-less is impossible if you want to handle interrupts at all, or you want process isolation. Which personally I do, because I do not relish the thought of my web browser crashing because my in-development application made a mistake. Most software you see these days is held together with string and prayers, and if you take the process isolation away, all hell will break loose.

Scheduling is performed via fully co-operative primitives expanded at compile-time through inline macros.

*flashes back to unresponsive Windows 3.1 sessions* Yeah, cooperative multi-tasking sounds awesome!

(However, if you cannot use i2p, there is a mirror over the clearnet at https://codeberg.org/vantheman/plan12)

Now, I had a look at this, and it seems that this repo only contains documentation and one weird assembler macro file that is not self-contained, so I have no idea what it is trying to do. So all you have up till now is good intentions? I am having trouble picturing this kernel-less architecture of yours, and you don't have a POC I could look at.

This is my first operating system

Then I would counsel you make something more traditional for starters, so you can find the faults with this. Picasso's first paintings were also very conventional. In fact, it is recommended to get experienced making applications inside an OS first before embarking on the journey of making an OS yourself.

[vantheman]

@nullplan,

1. The system does not handle interrupts. Polling is how interrupt-oriented hardware is handled (sounds crazy, but the architecture has native isolation and assignment of execution units so polling becomes semi-practical-ish. This is one of the trade-offs.)
Another major point is security through the user. If the OS architecture is simple enough, then software can be simple enough so you can read your web browser's entire source code in a week or so and make sure this will not happen. This is kinda the entire point - make the OS architecture simple to 'force' the applications to do the same. It allows the system to be simple all the way down instead of moving complexity.
2. This was a bit of a summarizing. They are more of primitives. The documentation clarifies they are generally used to emulate other kinds of schedulers, so the system is not strictly co-operative. (And again, due to the native execution unit isolation, the system allows every execution unit to run it's own psedo-scheduler)
3. I am learning the AMD64 architecture while making this OS (I have only had experience with the LSI11/03 and the MOS 6502 (I swear I am only 15 and not 75 I swear)) and it is mostly documentation (and a LOT of hopes and wishes) so you are essentially correct on this. Frankly, I am still figuring out the architecture myself so I am trying my VERY BEST to not write any meaningful code yet.
4. I have done a bit on UNIX theory and a little with BSD, but I am not a fan of the model, so I went to explore this instead as an alternative,

I would recommend reading the vp12 docs for '6.INDEV', as it covers these issues in a much more direct way.

Also, your bit on the 'all software is held together by strings and prayers', the point of this is to be a 'fresh slate' system based on simple, universally applied primitives without (or at least with few) edge cases

(Also, thank you so much for giving feedback on the system. This was very much appreciated.)