James Molloy's Tutorial Known Bugs: Difference between revisions

It is recommended that you follow the this wiki's standard tutorial [[Bare Bones]] before you begin with the tutorial. This ensures you get the a proper cross-compiler and use the proper compilation options. If you have already followed the tutorial, please compare your current build environment against the recommended practicepractices covered by [[Bare Bones]].

This attribute packs the associated structure. This is useful in a few cases, such as the idt and gdt code (actually just the idt, gdt and tss pointers). However, the tutorial tends to randomly attach it to everythingevery struct parameter, even where it isn't even needed. It is only needed where you want badly want aligned structure members, it doesn't do anything if all the structure members were already naturally aligned. Otherwise, the compiler will automatically insert gaps between structure members so each begins at its own natural alignment.

The interrupt.s file invokes the <tt>cli</tt> and <tt>sti</tt> in the interrupt handler to disable and enable interrupts, as if the author didn't know whether the interrupt handlers were run with interrupts on or off. You can control whether they are run with interrupts on and off by simply deciding it in your IDT entry for the particular interrupt. The <tt>sti</tt> during the interrupt handler end is also useless as <tt>iret</tt> loads the eflags value from the stack, which contains a bit telling whether interrupts are on or off; in other words the interrupt handler automatically restores interrupts whether or not interrupts were enabled before this interrupt.

The paging code isn't terribly good and it is worth it to fully understandingunderstand paging and design it all yourself. Paging code tends to be quite ugly, but it'll probably be decent after your fifth design revision. There is no need to always re-enable paging in <tt>switch_page_directory</tt>, it is likely best to have a special function the first time paging is enabled. The inline assembly in 6.4.5. doesn't need to be volatile as it is simply reading a memory value, which has no side-effects and it is acceptable if the compiler optimizes it away if the value is never used.

It is probably best that you write your own heap implementation.

It is strongly recommended that you write your own implementation of this and disregard the advisetutorial. The tutorial attempts to implement forking kernel threads by searching for magic values on the stack, which is insanity. If you wish to create a new kernel thread, simply decide which registers it should have and point its stack pointer at its freshly allocated stack. It will then start executing at your desired entry point. The part where it disables paging is bad and you should just map the source and destination physical frames at appropriate virtual addresses and memcpy with paging on at all times. Section 9.3 in particular is insanity and has blown up at least one well-established hobby operating system.

The tutorial isn't bad as an example, but its design isn'tis not optimal and some parts of it isare just plain bad (see multitasking). Indeed, you should just use it to get started and diverge from it as fast as possible, only using the tutorial when you need an example or can't implement it yourself. You should prefer consulting information on this wiki if possible. I haven't yet located all the problems in the tutorial, and some are quite minor and not technically problems but just small subjective design flaws. It is worth anticipating whether your future self will be removing tutorial code from your operating system and thus saving effort by never putting it there in the first place.