First of all, I apologize for the naiveness of this post and for most probably wasting your time reading it. Please take it as if we were in a pub having a chat with a beer (or two).
I have many years of programming experience in almost all main languages, but I don't have the knowledge in OSs nor free time enough for studing and researching about the necessary for building an OS from scratch more than copypasteing and modifiying basic tutorials. If that sounds bad already, just wait.
I have an idea for a monolithic kernel for experimenting and learning, which has two main layers: A base kernel which starts up the system and provides.an abstraction of the hardware, and a number of kernel "extensions" that use a very simple and unopinionated API provided by the base kernel to implement many "high level" features. The base kernel would always be the same (for a specific hardware arquitecture), and the kernel extensions would be the playground for testing different filesystems, memory organization, terminals and guis, etc. (I don't know if process scheduling could be decoupled too, but could be also cool to try different things).
I'm being very vague and confusing, probably because I don't understand how all this could be done. Being more specific, wouldn't it be cool to have a simple API with just some basic functions like:
- - sys_info() - information about system processors, memory, disks, screens, connected devices, etc..
- disk_read(disk_id, block, &ptr) and disk_write(disk_id, block, ptr)
- mem_read(block, &ptr) and mem_write(block, ptr) - fixed size memory and disk blocks.
- System starts in graphics mode and screen access is provided by writting and reading a frame buffer in a specific destination (with double buffer support by using another specific destination).
- read_event(&evt) - read event from queue of device events (USB, PS/2, ..)
- keyboard or mouse drivers could be in the base kernel, and would populate their status in specific memory areas.
* the base kernel would reserve some RAM area for its internals, invisible to kernel extensions.
** (I didn't put an example of API for handling multiprocessing and scheduling because I honestly don't know how it could be -_-).
I hope you get the idea. Simple, unrestricted, flat and abstract access to hardware.
My frustration is that hardware -specially nowadays- is incredibly complex, with lots of small tricks and wizardry, and at the end of the day the actual, final, logical operations are quite simple: read/write pixel, read/write memory and disks, check keyboard key or mouse button. That's it.
I understand that the complexity is due to all backwards compatibility, the insane amount of different devices, the complex and newest architectures… but for a moment forget about compatibility and think of the most common denominator, the most basic hardware and devices. Forget about supporting others. Forget about best performance. Forget about users and fame. Just think about simplicity and minimum hardware abstraction.
Could this be feasible? Don't you think it could be a nice base kernel for students to implement all kind of different OS's related techniques and algorithms without having to implement the whole SO? (for example, the teacher could provide the base kernel with all extensions but one that they have to implement)
- Does any existing kernel do this at some level, or can be easily modified for this?
- What would be the most suitable architecture? x86, x64? a RISC maybe? raspberry? powerPC? beagle?
I hope I didn't make you angry if all this is too stupid and naive. I buy the next round. Cheers!
I'll take a look.
This is too beautiful to be true. The api looks even simpler than what I thought it could be.. beautiful job, so neat, so lightweight..