[email] Night Kernel ideas and suggestions

[Maarten Vermeulen]

We got an email with a few ideas and suggestions about the kernel. Now, I have some comments on this myself. But I'm going to use this initial post as a recap of his email and I'll post a reply (which may take a few minutes to write) right after this one with my own comments about this.

His vision for a 32-bit DOS drop-in replacement can be split into four different parts:

• A 16 bit bootloader that sets the stage for 32-bit, it would also act as a monitor (I guess he means like the feedback you get on-screen with Ubuntu Server, FreeDOS etc. He gave Minix as example)
• The Kernel itself: the essential hardware drivers (but only the ones necessary at boot time), memory manager, virtual filesystem layer and a WM86 process manager
• The remaining 32-bit drivers as loadable kernel modules
• The 16-bit DOS compatibillity layer, which gets called when the kernel wants to do VM86 stuffWe won't need a fully fledged DOS emulation layer, just one for the BIOS. But it would be certainly possible to have one.

He also explains that the kernel, will need an interval timer (the PIT in our case) if it wants to support the pre-emptive multitasking. The timer should call the scheduler, the scheduler should handle the time-of-day and not by the handler of the ISR itself.

Screenshot:

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The updating and maintaining of the task queue(s) can be run as seperate tasks. And note the word 'task' not process (task is strictly kernel level, process is user level).

Then there are a few other (smaller) suggestions:

• update time-of-day by task scheduling, not the interrupt handler
• we store time-of-day in different fields, another way would be using a single counter and convert the count (e.g. microseconds) to human-readable format
• clock may drift: one way to solve would be to use the RTC (Real Time Clock) of the PC regularly to update system time

Screenshot:

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

[Maarten Vermeulen]

On Sunday, July 8, 2018 at 11:39:45 PM UTC+2, Maarten Vermeulen wrote:

His vision for a 32-bit DOS drop-in replacement can be split into four different parts:

• A 16 bit bootloader that sets the stage for 32-bit, it would also act as a monitor (I guess he means like the feedback you get on-screen with Ubuntu Server, FreeDOS etc. He gave Minix as example)
• The Kernel itself: the essential hardware drivers (but only the ones necessary at boot time), memory manager, virtual filesystem layer and a WM86 process manager
• The remaining 32-bit drivers as loadable kernel modules
• The 16-bit DOS compatibillity layer, which gets called when the kernel wants to do VM86 stuffWe won't need a fully fledged DOS emulation layer, just one for the BIOS. But it would be certainly possible to have one.

This mostly aligns with a graph that was made when this project started (see below). We could previously find this at github, but not anymore. I think we should bring documentation like this back, so people can see it. If not a github, then the website is a great place. (I still have most of the old documentation)

And may I update the welcome message of the group so that it includes the website? We can also create a read me on GitHub with info like this.

[Maarten Vermeulen]

[Mercury Thirteen]

On Sunday, July 8, 2018 at 5:39:45 PM UTC-4, Maarten Vermeulen wrote:

We got an email with a few ideas and suggestions about the kernel. Now, I have some comments on this myself. But I'm going to use this initial post as a recap of his email and I'll post a reply (which may take a few minutes to write) right after this one with my own comments about this.

His vision for a 32-bit DOS drop-in replacement can be split into four different parts:

• A 16 bit bootloader that sets the stage for 32-bit, it would also act as a monitor (I guess he means like the feedback you get on-screen with Ubuntu Server, FreeDOS etc. He gave Minix as example)
• The Kernel itself: the essential hardware drivers (but only the ones necessary at boot time), memory manager, virtual filesystem layer and a WM86 process manager
• The remaining 32-bit drivers as loadable kernel modules
• The 16-bit DOS compatibillity layer, which gets called when the kernel wants to do VM86 stuffWe won't need a fully fledged DOS emulation layer, just one for the BIOS. But it would be certainly possible to have one.

This is pretty much how the kernel will be... eventually. Right now, for example, we have drivers integrated as part of the kernel, but in the end they will all be standalone programs running in ring 2 or 1, not built into the kernel itself.

 

He also explains that the kernel, will need an interval timer (the PIT in our case) if it wants to support the pre-emptive multitasking. The timer should call the scheduler, the scheduler should handle the time-of-day and not by the handler of the ISR itself.

We do have the PIT mapped to interrupt 0x20 which does handle maintenance of the system clock time. An interface to the task scheduler will be added once multitasking is added. It would be nice to eventually spin this functionality off into its own legacy driver, but I'm concerned that it'll become too much like Windows XP if that much latency is introduced. We'll have to see how things play out on that one.

 

Screenshot:

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The updating and maintaining of the task queue(s) can be run as seperate tasks. And note the word 'task' not process (task is strictly kernel level, process is user level).

Then there are a few other (smaller) suggestions:

• update time-of-day by task scheduling, not the interrupt handler
• we store time-of-day in different fields, another way would be using a single counter and convert the count (e.g. microseconds) to human-readable format
• clock may drift: one way to solve would be to use the RTC (Real Time Clock) of the PC regularly to update system time

Priority-based scheduling with a single task queue is what I had in mind for Night, but I kinda like the sound of multiple task queues as well. Another thing to look into when the time comes. :)

 

Screenshot:

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

I changed it to:

test dword [tSystem.configBits], 000000000000000000000000000000100b

jz .stickWith25

which worked great. Thanks! 

[Mercury Thirteen]

IIRC, I think we stripped the documentation folder from the GitHub to keep it code-only. But we could definitely add a section to the website for such things. And yep, feel free to modify the group! Let's keep the GitHub reserved for just code, though.

[Maarten Vermeulen]

Soon...

And yes, I'm going to call it that.

[Mercury Thirteen]

Sweet. DocHub is go!

Just to be clear, I don't have a problem with adding a folder for documentation later on, but only once we actually have a cohesive set of documentation to use. Right now it's mostly a bunch of loosly-related documents which may make sense to us but would probably only confuse others. I think the website would be a better place for that at the moment. 

[Maarten Vermeulen]

Should we name it 'Dochub' or 'Documentation hub'?

Secondly, we should just select the things we want on it. It probably won't be a folder, but just a page with pictures and some description.

[Mercury Thirteen]

On Wednesday, July 11, 2018 at 5:11:15 PM UTC-4, Maarten Vermeulen wrote:

Should we name it 'Dochub' or 'Documentation hub'?

It could be either. Maybe DocHub sounds a little too GitHub-y?

 

Secondly, we should just select the things we want on it. It probably won't be a folder, but just a page with pictures and some description.

Sounds good to me!

[Maarten Vermeulen]

On Wednesday, July 11, 2018 at 11:37:53 PM UTC+2, Mercury Thirteen wrote:

On Wednesday, July 11, 2018 at 5:11:15 PM UTC-4, Maarten Vermeulen wrote:

Should we name it 'Dochub' or 'Documentation hub'?

It could be either. Maybe DocHub sounds a little too GitHub-y?

Haha, maybe it does... Documentation Hub it is! :)

I don't know, you decide! :P