OSDev.org

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!

Hi, and welcome to our forums. First of all, there are no stupid questions. I don't think your question has already been asked, so you're not wasting our time.

Your idea of separating hardware access and individual drivers is actually not stupid and it is feasible. In fact, the widespread monolithic kernels all do this to some extent. Linux' core for example consists of things like memory management and a VFS API but the actual drivers are can be compiled to separate modules.

A good way to achieve this on x86 is to provide an API that allows access to IRQs and to the PCI BARs. These two interfaces suffice to interface with most PCI(e) hardware, which is almost all hardware in a modern PCs.

Thank you for the warm welcome

Thanks for the tips around IRQ and PCI, that can simplify things quite a bit.

Maybe I could find a mini linux-inspired kernel and build an API like I mentioned on top of it..

Hi,

feiss wrote:Maybe I could find a mini linux-inspired kernel and build an API like I mentioned on top of it..

I'm wondering if maybe you might get more (from a theoretical perspective and for inspiration) from an exokernel like Nemisis or one of MIT's prototypes.

Exokernels have the same "low level kernel API for abstracting the HW" that you seem to be looking for (just with "kernel extensions" implemented as a shared library or libraries in user-space, instead of implemented as kernel modules).


Cheers,

Brendan

Oh, thanks a lot! An exokernel fits quite well to what I was rambling about indeed I'll take a look.

Hi feiss,

This is pretty similar to what I'm working on at the moment: https://github.com/ReturnInfinity/BareMetal-kernel

The kernel just contains what is needed to use the hardware. Higher level software will provide higher level abstractions like a file system and TCP/IP (if needed).

Best regards,
Ian

Similar?? it is almost the same!! 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..

I'll give it a try when I have the chance. Thanks for replying!