Why are "Call Gate" & "Task Gate" necessary?

Firstly, when someone wants to "jump to or call" procedure in another segment(which is a non-conforming code segment with a higher privilege level than caller), they may use "Call Gate".
But, in my opinion, this is not necessary.
Since ever anyone wants to do that, just use "INT" opcode in order to excute a procedure programmed in a higher code segment as likely as "SERVICE CALL" used in many popular OSs, such as Windows and Linux.
So i can't imagine WHY "CALL GATE" IS EXIST!!

Secondly, the "Task Gate"! you know, "task switching" can be perfomed without "Task Gate"!
Just copy some registers and change its value.
So! i really don't know and catch the purpose of WHY "TASK GATE" is EXIST!!

anyone who has any idea about these..... plz help me.. save me! :confused:
thankyou for reading.

Posted on 2003-08-12 06:59:59 by Yeori
Well first of all INTs are intended for exceptions and hardware IRQs and NOT for API calls. The fact that Linux and by copy Windows kernel parts use them like that is a mistake IMHO.

INTS can not use paramaeters on stack and have to use registers to transfer them, arguabely but true this method of parameter transfer is slower and more problematic with many parameters

As FreeBsd shows the Callgates are faster than INTs whan used for OS API

So Callgates SHOULD be used for OS API!

Besides the entrys in IDT are just a version od a callgate but without the advantage of parameter transfer (however with other advantages specific to IRQs)

Task Gates are the standard way to use TSS and task switch also. The fact that Windows and Unix use different method is just a HACK for speed purposes :D

Not very safe BTW
Posted on 2003-08-12 10:54:05 by BogdanOntanu
today i found out the real sense of task gates. they are an entry in the idt. if an interrupt occours and that goes to the task gate the cpu switches to that task. this is needed in the following case:

if you use paging and a program pushes parameters on the stack - in an endless slope. somewhen a push will generate a pagefault, the cpu wants to jump to the interrupt-handler, if its a normal exception handler. it wants to push the cs:eip and the eflags on the stack - but that's not possible since a push generates a page fault. finally the cpu comes to a triple-fault and the cpu resets - so, just because a ring0-task overflows its task the system resets.
this won't happen if you use a task gate, the cpu will push the parameters (cs:eip and eflags) on the new tasks stack.

@BogdanOntanu: actually it's possible to use ints for apicalls with the parameters on the stack, i've implemented it in my os - it was difficult anyway and slow, i guess. but i want to find a better way :) (-> callgate?)
Posted on 2003-08-12 15:21:50 by hartyl
BogdanOntanu, do you have a reference to a discussion of the speed of call gates / task gates / INT's? Is this slowness on all CPU's? Is there any way to speed it up? Personnally, I'd prefer to use the mechanism as outlined by Intel mainly because of the hardware protection of code (can the same level of protection be achieved in code?).
Posted on 2003-08-12 16:41:40 by bitRAKE
Operatings system calls shouldn't need to be fast. If applications need to call operating system functions in a tight loop, then the application and/or system design is probably flawed. Why not go for the Windows approach? Have some of the system be running in user mode to avoid the overhead.
Posted on 2003-08-12 17:16:10 by Sephiroth3
(Probably off topic)
Originally posted by Sephiroth3
Operatings system calls shouldn't need to be fast.

I agree this part in general, but,

If applications need to call operating system functions in a tight loop, then the application and/or system design is probably flawed.

I don't really understand what you mean here.
For example, reading in standard input is usually implemented like this:
(FreeBSD syscall, MASM-like pseudo code)

push 1
push offset char_variable
push 0
int 80h
lea esp,[esp+12]
jc error
; do something with input
jmp read_again

I'm just curious what you would say about this loop, especially when stdin is redirected.
Posted on 2003-08-12 18:04:05 by Starless

Why not go for the Windows approach? Have some of the system be running in user mode to avoid the overhead.
Because it would be flawed (in regaurd to protection) in a way that is not fixable by additional software. :)
Posted on 2003-08-12 19:49:06 by bitRAKE
Starless: The system could have an API that reads a whole line at a time, which would solve the problem. And the first disk access would be slow anyway. The part where it does something with the input would also usually take some time (for example, in a command-line interpreter that reads a shell script that starts a compiler).
Anyway, a call to a call gate takes 7 bytes, whereas an interrupt call takes 2. This could make programs bigger if they use a lot of system calls. But hey, who says you can't have both? There could be a call gate and an interrupt that both put you into system code, and you could use the call gate when you want that tiny speed increase.

bitRAKE: I was thinking of having the "safe" part in user mode. For example, it could be a library that translates key codes, handles synchronization (by setting some flags in a structure that the system mode part would check when switching threads), or performs other version-specific functions that are still safe to handle in user mode.
Posted on 2003-08-13 04:00:48 by Sephiroth3