OSDev.org

Ive been reading intels docs, and if I understand this correctly, can you have multi-tasking by letting the hardware do all the work? All you would have to do is setup all the descriptor tables, setup TSS entries for whatever processes you want to run and enter them in the TGT, and then have your scheduler just execute a call instruction on an entry in the TGT pointing to the process you want to switch to? Is it really that simple(conceptually)?

You mean the GDT, and yes it pretty much works that way, only in reverse - the scheduler *returns* to a task, and the task interrupts/calls into the scheduler

Hi,

yemista wrote:Ive been reading intels docs, and if I understand this correctly, can you have multi-tasking by letting the hardware do all the work? All you would have to do is setup all the descriptor tables, setup TSS entries for whatever processes you want to run and enter them in the TGT, and then have your scheduler just execute a call instruction on an entry in the TGT pointing to the process you want to switch to?

AFAIK most people who used hardware task switching end up using a JMP to the new task, so that they don't need to mess with backlinks...

yemista wrote:Is it really that simple(conceptually)?

In thoery, in can be that simple, and AFAIK it was designed so that (potentially) any task could switch to any other task without scheduler involvement.

In practice, it's slow (e.g. a lot of data can be saved/restored for no reason) and the scheduler needs to do extra work that isn't included - making sure 2 different CPUs don't accidentally try to run the same task, keeping track of time used by each task, changing other CPU state (e.g. debugging registers), changing any OS state, fudging GDT entries so that it can handle more than 8190 tasks, etc.

Basically, using hardware task switching doesn't really make implementing multi-tasking any easier, it's worse for performance, and it's less flexible.


Cheers,

Brendan