flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Sequence in designing OS kernel?

Author
Thread Post new topic Reply to topic
FlierMate



Joined: 21 Jan 2021
Posts: 208
FlierMate
Hi all! I would like to know what is the proper sequence in designing an OS kernel?

These are the basics:
Quote:

Bootloader >> Kernel stub >> Kernel (in HLL) >> Text mode console


Then from various sources, I further understand that GDT and IDT should be in early stage of building an OS. However, I do not have the full long list.

It would be good if someone can give the list in regards to: What are the different parts of OS kernel to build, and their sequences.

For example, I want my OS kernel to catch exception and dump stack trace, which part is related to this?

I know I should have asked this on forum.osdev.org, but I am not familiar with community there. The forum rules state members must "ask smart question", while this question is a dumb question.
Rolling Eyes

Also, I understand that my OS kernel (in the future) will be written in HLL, because not everyone is capable like Ville (and the MenuetOS team) to write everything completely in Assembly language.

Have a good day everyone.
Post 16 Jan 2022, 15:01
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 462
Location: Russia
macomics
It seems to me that after that you will need more access to the disk and after that you can create an automated development environment under the control of your kernel already. This is necessary to speed up development in order to get rid of the need for constant rebooting / reloading with each build of your kernel. For development, you will need 3 utilities. A text editor (possibly with an external invocation system), a compiler and a kernel-mode debugger.

FlierMate wrote:
These are the basics:
Quote:

Bootloader >> Kernel stub >> Kernel (in HLL) >> Text mode console


Have you already implemented all of the above?
Post 16 Jan 2022, 15:22
View user's profile Send private message Reply with quote
FlierMate



Joined: 21 Jan 2021
Posts: 208
FlierMate
macomics wrote:

FlierMate wrote:
These are the basics:
Quote:

Bootloader >> Kernel stub >> Kernel (in HLL) >> Text mode console

Have you already implemented all of the above?


Yes, I even went two further steps, to support PS/2 keyboard and enumerate all PCI devices. Smile

macomics wrote:
It seems to me that after that you will need more access to the disk and after that you can create an automated development environment under the control of your kernel already. This is necessary to speed up development in order to get rid of the need for constant rebooting / reloading with each build of your kernel. For development, you will need 3 utilities. A text editor (possibly with an external invocation system), a compiler and a kernel-mode debugger.


This is really a good thing to know! It is new to me, and I like this idea very much.

However, I am still in early beginning, I do not know what are:
1. KHeap
2. Heap
3. Paging
4.......

As I do not have solid foundation in OS theory and CPU architecture, or anything related to allocation of RAM and CPU resources, because I learn by doing. Surprised

Thanks, macomics, for your guidance in the past.
Post 16 Jan 2022, 15:30
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 462
Location: Russia
macomics
FlierMate wrote:
However, I am still in early beginning, I do not know what are:
1. KHeap
2. Heap
3. Paging
4.......
For the three tools described above, memory management is not yet necessary. And the mechanisms can work both in virtual memory and in a flat model of physical addressing. When developing a kernel-mode debugger, you will simultaneously create prototypes of memory management mechanisms. So, it seems to me that the path I have proposed will also tell you what should be developed next.
Post 16 Jan 2022, 15:42
View user's profile Send private message Reply with quote
FlierMate



Joined: 21 Jan 2021
Posts: 208
FlierMate
macomics wrote:
FlierMate wrote:
However, I am still in early beginning, I do not know what are:
1. KHeap
2. Heap
3. Paging
4.......
For the three tools described above, memory management is not yet necessary. And the mechanisms can work both in virtual memory and in a flat model of physical addressing. When developing a kernel-mode debugger, you will simultaneously create prototypes of memory management mechanisms. So, it seems to me that the path I have proposed will also tell you what should be developed next.


At least I have a direction or keyword ("kernel-mode debugger") to search.

But what about ISR, it is related to IDT. The example PeachOS that I am studying can support ELF loader and basic syscall.
Post 16 Jan 2022, 15:47
View user's profile Send private message Visit poster's website Reply with quote
macomics



Joined: 26 Jan 2021
Posts: 462
Location: Russia
macomics
I'm afraid that for your kernel you will need not a ready-made solution, but a unique utility. kernel-mode debugger is just tied to the specific designs of the operating system kernel. If you take a ready-made solution, then with a high degree of probability you will make a clone of the system for which the debugger was created. But as a text editor and compiler, you can try to take fasmd from the DOS kit.
Post 16 Jan 2022, 15:57
View user's profile Send private message Reply with quote
moogloof



Joined: 25 Feb 2022
Posts: 1
moogloof
FlierMate wrote:
macomics wrote:
FlierMate wrote:
However, I am still in early beginning, I do not know what are:
1. KHeap
2. Heap
3. Paging
4.......
For the three tools described above, memory management is not yet necessary. And the mechanisms can work both in virtual memory and in a flat model of physical addressing. When developing a kernel-mode debugger, you will simultaneously create prototypes of memory management mechanisms. So, it seems to me that the path I have proposed will also tell you what should be developed next.


At least I have a direction or keyword ("kernel-mode debugger") to search.

But what about ISR, it is related to IDT. The example PeachOS that I am studying can support ELF loader and basic syscall.


It's been like a year, but I'll just reply. I assume you probably figured it out already, but an ISR is an Interrupt Service Routine and an IDT is an Interrupt Descriptor Table. ISRs are basically functions that the CPU will jump to when it is signaled an interrupt. An interrupt can be system calls, alerts from hardware, or exceptions. The IDT basically contains the addresses and information about your ISRs, so that the cpu knows where to look for them.

I don't know about PeachOS, but I recommend you read up on all of these keywords before diving into development. Trust me, I figured out the hard way. Hope you made progress!
Post 25 Feb 2022, 03:09
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.