OSDev.org

i read the os design introduction linked by
http://www.osdev.org/osfaq2/index.php/all%20in%20one

the link points out the order the os implementer may follow

• [1]
  Being able to print strings and integer numbers (both decimal and hex) to screen certainly is a must at early stage. This is one of most basic ways of debugging, and virtually all of us have gone through a kprint() or kout in version 0.01.
  [2]
  You are likely to make mistakes when going further, so having a working and (once again) reliable interrupt/exception handling system that can report you the address of the fault as well as the register contents will be a valuable help aswell.
  [3]
  Having the opportunity to allocate memory at run-time (malloc()-like interface) for your kernel's internal structure will certainly come handy sooner or later. It is suggested you handle it soon.

now I am wandering at the step 2, I don't know how to realize one reliable interrupt/exception handling,

i also searched the related info and read them, had no idea yet.

below on that page, you should see Help!? My kernel Crashed! which features an example exception handler.

When i say "reliable" here, i mean "you should have tried to raise exceptions and checked that the state summary you display is correct".

e.g. which should trigger a GPF. Check that you can retrieve 0x1234567 and 0xcafebabe on the stack, and that retrieved EIP of the crash is indeed the address of "crash".

Hi,

Pype.Clicker wrote:When i say "reliable" here, i mean "you should have tried to raise exceptions and checked that the state summary you display is correct".

Oddly, this is something I haven't thought of doing for my latest rewrite, even though all the display code, etc is in place.

It's not that I haven't had my fair share of bugs, but it does make me wonder if telling Bochs not to reset on triple faults is good enough for most things that happen during early development.


Cheers,

Brendan

Brendan wrote: It's not that I haven't had my fair share of bugs, but it does make me wonder if telling Bochs not to reset on triple faults is good enough for most things that happen during early development.

Yes, that might be a viable option as long as you're running only in the bochs ... but which makes you completely clueless when you'll be running your system on bare hardware (and, imho, the sooner the better: trying to figure out why 64K of new code works only in a bochs may turn into a nightmare)