About a kernel API for abstracting the HW

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Post Reply
feiss
Posts: 4
Joined: Fri Sep 08, 2017 5:12 pm

About a kernel API for abstracting the HW

Post by feiss »

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). :oops:

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).

Image

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! :wink:
Korona
Member
Member
Posts: 1000
Joined: Thu May 17, 2007 1:27 pm
Contact:

Re: About a kernel API for abstracting the HW

Post by Korona »

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.
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].
feiss
Posts: 4
Joined: Fri Sep 08, 2017 5:12 pm

Re: About a kernel API for abstracting the HW

Post by feiss »

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..
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: About a kernel API for abstracting the HW

Post by Brendan »

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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
feiss
Posts: 4
Joined: Fri Sep 08, 2017 5:12 pm

Re: About a kernel API for abstracting the HW

Post by feiss »

Oh, thanks a lot! An exokernel fits quite well to what I was rambling about indeed :D I'll take a look.
User avatar
IanSeyler
Member
Member
Posts: 326
Joined: Mon Jul 28, 2008 9:46 am
Location: Ontario, Canada
Contact:

Re: About a kernel API for abstracting the HW

Post by IanSeyler »

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
BareMetal OS - http://www.returninfinity.com/
Mono-tasking 64-bit OS for x86-64 based computers, written entirely in Assembly
feiss
Posts: 4
Joined: Fri Sep 08, 2017 5:12 pm

Re: About a kernel API for abstracting the HW

Post by feiss »

Similar?? it is almost the same!! :shock: 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!
Post Reply