OSDev.org

I've recently been working on my C++ kernel, and in particular paging. While I was doing that, I had the idea to make my Console class follow the singleton model. However, it's stopped working. Bochs with debugging complains with the message 'failed assertion "(addr & 0xf) == 0" at apic.cpp:339', which strikes me as odd - my implementation just writes to B8000 in memory, and I didn't think that memory writing went through the APIC. My error lies in the GetInstance() method, and I would guess that within that, the call to InitialiseConsole(), but I don't see why; all it does is assign hard-coded values to variables. Since I don't do anything special before getting the console (it's the first thing I do after calling the constructors for global variables, which there are none of), I presume that GrUB or my loadConstructors() method messes up the location of the video memory. My code files are attached

Is your placement new working well? I can only think of it allocing your nodes just into the apic memory zone.

Cheers,
Gonzalo

I've just gutted my placement new, and you are indeed correct. There was a reference to my broken paging code which I hadn't noticed. Removed that, and everything works. Still, at least I now know that my AllocateMemory function works. When paging is working, I'll put it back in and finally get some 'proper' C++ compiler support. Thanks

computafreak wrote:I've recently been working on my C++ kernel, and in particular paging. While I was doing that, I had the idea to make my Console class follow the singleton model.

My OO teacher did not like Singletons, and he was mostly right: what if in the future you want to handle many consoles?

JJ

When I was writing the class, I thought that in the future, when I implement threading, having two instances of the same class writing to the same point in memory at nearly the same point in time would be chaotic - the user could miss some information being printed on the screen because another instance overwrote it on the next thread switch

Well, you can perfectly use a semaphore or a mutex to avoid that.

Just remember to ENABLE interrupts while the (for example) "write to screen" syscall is waiting, otherwise your system cpu usage will be higher and kernel will be waiting while it could have run another thread.

Cheers,
Gonzalo

computafreak wrote:When I was writing the class, I thought that in the future, when I implement threading, having two instances of the same class writing to the same point in memory at nearly the same point in time would be chaotic - the user could miss some information being printed on the screen because another instance overwrote it on the next thread switch

This can be solved by other (better) means.
For example, you could use a Strategy. Provide a method to change the printing mechanism at runtime. That method would then change the low-level object that actually performs the printing.
This is adequate, since you sometimes want to disable the actual printing when the foreground process changes.

Now it came to my mind an Observer together with that Strategy. Have the console do the buffering and notify the display driver when the buffer is written to. The driver could then extract the needed information from the console in order to update the display.
When you want to change the foreground process, just change the Strategy to one that doesn't notify the driver.

JJ

That seems to be a variation of what I'm trying to do. My Console class derives from a Stream object and my keyboard driver accepts an OutputStream property. If I want, I simply swap the Console instance with, say, a NetworkStream instance. I like the idea about using an Observer pattern though; I'll have a look at that. The idea about mutexes and semaphores will probably come in handy later as well. Thanks