Sequence in designing OS kernel?

Index > OS Construction > Sequence in designing OS kernel?

Author

Thread

FlierMate

Joined: 21 Jan 2021
Posts: 219

FlierMate 16 Jan 2022, 15:01

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.

16 Jan 2022, 15:01

macomics

Joined: 26 Jan 2021
Posts: 1013
Location: Russia

macomics 16 Jan 2022, 15:22

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?

16 Jan 2022, 15:22

FlierMate

Joined: 21 Jan 2021
Posts: 219

FlierMate 16 Jan 2022, 15:30

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.

16 Jan 2022, 15:30

macomics

Joined: 26 Jan 2021
Posts: 1013
Location: Russia

macomics 16 Jan 2022, 15:42

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.

16 Jan 2022, 15:42

FlierMate

Joined: 21 Jan 2021
Posts: 219

FlierMate 16 Jan 2022, 15:47

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.

16 Jan 2022, 15:47

macomics

Joined: 26 Jan 2021
Posts: 1013
Location: Russia

macomics 16 Jan 2022, 15:57

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.

16 Jan 2022, 15:57

moogloof

Joined: 25 Feb 2022
Posts: 1

moogloof 25 Feb 2022, 03:09

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!

25 Feb 2022, 03:09

< 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