Tutorial 16: Kernel: Timing and Exception Handling

[Mike]

Hey everyone,

Tutorial 16 should be up soon. It integrates everything form the PIC and PIT tutorials into full interfaces within the Hardware Abstraction Layer (HAL) for use by the kernel. This includes processor exceptions and our own BSoD. It (hopefully) will be up within this week.

This also means this is the beginning of us handling other hardware devices, such as the keyboard. To spice things up a little, I might also add some support for keyboard input.

---

Tutorial 17 will go back to the kernel itself and start adding memory management, paging, and mabey even task management support. It will be fun

[pathos]

I've had pretty good luck being able to figure out exceptions and hardware on my own, but paging is something I just can't get right. That's not to say I'm not excited about Tutorial 16 -- can't wait! But things will really start coming together with 17.

[gzaloprgm]

Paging is easy, Dynamic memory allocations is harder.

For paging, basically you'll need a page directory for kernel and one extra per process (if you want it).

Then you should have a way of knowing which frame is free and which isn't (for example with a bitmap).

You also need some way of allocating page tables dynamically and setting to which frame is it mapped to.

I haven't implemented it on my kernel, but you can see a tutorial http://www.osdever.net/tutorials/paging.php and http://jamesmolloy.co.uk/tutorial_html/6.-Paging.html

Cheers,
Gonzalo

[Mike]

The next tutorial should be up sometime in the next few days...Mabey even this weekend.

The demo itself starts building on the interface for the HAL for the kernel and device driver software.

I do not think I will add keyboard support here because it will add more complexity to the demo source and tutorial. We might start working on a tutorial for keyboard programming, however, and build a keyboard driver for it a little later on, though..

We are currently cleaning up and final revisions of the demo code and tutorial. Afterwords, its uploading time

[Mike]

I am planning on the tutorial and next demo to be uploaded later on today. I will also be looking for comments on the loads of code in the next demo as well

If you have already read the PIC and PIT tutorials, this one should not be to bad. If not, I recommend reading those before going into this tutorial.

As always, please let me know what you think of it

[Mike]

Hey everyone,

The tutorial+demo has been uploaded. Most of it may not be very new if you have already read the PIC and PIT tutorials. This tutorial even encourages readers to read those tutorials.

In the next tutorial ("Tutorial 17: Paging and Virtual Memory") we go into alot of detail about physical memory and virtual memory, paging, and implementing paging. Its going to be another big information-packed tutorial, so I hope everyone is ready for it

[Andyhhp]

Sounds great - cant wait for tutorial 17.

As for tutorial 16, I have a few comments.

In the Hal files for the PIT and PIC, you use a huge number of define statements and pass data between functions as integers.

Purely as mechanism to prevent stupid errors (partly because no programmer is immune to them; certainly not me, and because stupid errors will really mess a kernel up if not realized), wouldn't it be better to pass all the constants as part of enumerations? This would have the advantage that, if someone decided that they wanted to pass a number, not a specific element of an enumeration, they would have to explicitly cast it. This means that if they didn't intend to, the possible error would be caught at compile time rather than knowing there was a bug somewhere in the huge mass of code if the kernel crashed.


On a different note, I realize that you are trying to write the kernel to be both C and C++ compatible but what is the point of having C++ compatibility without using its Object Orientated design?

For my kernel, I am not trying to have the C compatibility. Everything I can is implemented as classes, using as much of the 'hide as much of the innards as possible' so the programmer doesn't need to, nor has access to, the inner workings (also along the Pandora's box idea from one of the earlier tutorials).


And on a complete side note, I would like to thank you for everything you have done on the OS development series. Because of my interest (which is a result of finding this site ), I now have an interview to work at a company called Symbian in which, if I get a job, I will be doing something very akin to this for top of the range mobile phones.

Andrew

[Mike]

Purely as mechanism to prevent stupid errors (partly because no programmer is immune to them; certainly not me, and because stupid errors will really mess a kernel up if not realized), wouldn't it be better to pass all the constants as part of enumerations?

It would be alot better if it was indeed in an enumeration or, in C++, defined const. (I was originally thinking about this, actually.) Does standard C support enums? If so, then I just might update the demo code to using enumerations instead

On a different note, I realize that you are trying to write the kernel to be both C and C++ compatible but what is the point of having C++ compatibility without using its Object Orientated design?

The kernel does follow OOP design concepts (The implementations are encapsulated behind common interfaces for each object.) It does not use the OOP features of C++ (ie, classes), however, for better portability with C.

If you feel something can have a better design, feel free to let me know

I personally would prefer to use C++'s OOP features. However, most of the OS development community uses GCC, which does not support that.

I have been considering creating a "C++ version" of the demos, though..

And on a complete side note, I would like to thank you for everything you have done on the OS development series. Because of my interest (which is a result of finding this site Smile ), I now have an interview to work at a company called Symbian in which, if I get a job, I will be doing something very akin to this for top of the range mobile phones.

Congratulations! I hope you get it! Let me know how it goes, and good luck

[Andyhhp]

According to several websites including Microsoft, standard C does support enums for the specific purpose of reducing the number of #define statements that are present.

As for classes in C++, I didn't realize that GCC doesn't support them.

For design, i didn't mean to imply that is was a bad design, I merely meant that I had a different design.

Mine is something like this:

Kernel.dll:
This contains all the kernel specific stuff (code to get the dll to physically run). after setting up things like global constructors, it calls kmain(); Explicitly links to Hal.lib.

Hal.lib:
This contains (well - will when I have time) a set of namespaces containing group-able parts of the hal, similar to the package structure of the java librarys (and the .NET libraries to a lesser extent).

currently it contains:
namespace core: memset/memcpy functions
namespace screen: class console: class dealing with writing to the screen

I will be adding (when time allows):
a namespace containing classes to deal with the GDT and IDT (and LDTs when we get onto them)
a namespace with classes to interact with specific chips (PIC and PIT so far)

I think that this is a clear design which makes top-level coding clearer but, as I said, this isn't necessarily a better design, just a different one.