OSDev.org

The whole screen is redrawn at 60Hz (fps), all the time. It goes through all the tasks and calls-back to draw their windows. If it hits a break point, what's it supposed to do? Abort that task's call-back, I suppose, over and over at 60Hz.

Viva la difference. My code is simple because I draw everything at 60fps. My biggest concern is video games... which are full screen and update 60fps worst case.

SparrowOS wrote:My breakpoints are owned by a task. When the task is run, I insert its breakpoints; when it is suspended, I remove them so the next task doesn't hit them. I have a special task which call-backs to refresh the screen and that screws-up your debugging because it's a different task from the task that owns the window. I started doing an IDE debugger, but it's worthless.

Inserting breakpoints in kernel code is my next best alternative for debugging (using the userland debugger to step into kernel space is the best, but it is unavailable for 64-bit code until I have a supported debugger). The exception-handler for int 3 will save register content in the thread control block, suspend the thread in the special debug list, and then schedule the next thread. Many of the exception handlers also put threads in the debug list if they cannot resolve the cause of an fault. I then have an interactive process in kernel space which I call "kernel debugger", which can inspect threads in the debug-list, change register state, and single step / restart them. In the production release, the presence of threads in the debug list causes reboots.

This project is now approaching it's end (64-bit support implemented in kernel). I can now see and modify 64-bit registers in the kernel debugger. I still need to relink the long mode faults to debug-list, and make some fixes for pacing code, but other than that it all seems to work very well. And it clearly took much lesser time than writing a 64-bit kernel from scratch.

Edit: All the relevant fault handlers are updated. I've also verified the IST-concept with TR loaded in protected mode, and just as I anticipated, the processor loads the IST stack from the TSS as if it was a 64-bit TSS. I tested it by setting up double fault handler with IST, and generated a double fault by modifying RSP in kernel debugger, and I can make the double fault handler enter the crash debugger even if kernel stack is corrupt before double fault is invoked.

Then I put the long mode thread in an infinite loop, but unfortunately that seems to kill all tasks on the processor, but not the IRQs.

I just solved the final issue with long mode threads in kernel mode. Seems like I temporarily commented-out a few lines of code in the syscall that unlocked the scheduler when testing long mode, and then forgot to remove that again, so instead of switching thread in a locked state, the processor just left the lock taken, which caused a hangup (or crash).

After that is fixed, I can both run the long mode process 10,000 times per second, and let it execute in a loop, with no yields, forever, without killing the system.

IOW, the kernel part of long mode support is now finished.

I have locks on documents. The command-line is a document. When you PutS() it inserts text into the command-line document. The Window manager updates the entire screen 60Hz by calling callback functions and doing all documents for all tasks. The Window manager locks documents and goes through them, writing to the screen. It does not wait forever on the lock, however -- it gives-up and leaves the windows blank.

I have preemption. Each task can turn-off preemption with a bit. When you spawn a task, preemption is off, by default.

When you do disk I/O, it does not use interrupts, it spins in a while-Yield(); loop. My tasks can change 3,000,000 times a second. I do not break disk requests in pieces, so one task will lock the drive until it's done. CPU is free though.

I never change privilege levels out of ring-0. I never use SYSCALL, just CALL.

There is no way to turn of preemption in my OS, and I even removed the "yield" / "swap" syscall a while back because nothing used it. In order to not busy-wait, threads either need to wait a fixed time, or block waiting for events.

BTW, I've also finally managed to remove all cli/sti instructions previously used for IRQ-synchronization, and replaced them with spinlocks. After redoing the physical memory manager to a lock-less implementation, I know also have a very stable SMP version that seems to run as well as the single-core version.

IOW, the SMP-port now seems to be done as well.