OSDev.org

When a hardware interrupt is generated, usually all register values are saved on the kernel stack...
but I have seen, in minix 3.1 that eax ebx, ecx, edx , est are not saved at all, only esi is preserved,

also I have seen in some context switch code, that the registers are not saved at all,,,

what are the considerations for determining whether registers should be saved, and if so, which ones?

You are mistaken.

The interrupt handlers in Minix 3 all use the macro SAVE_PROCESS_CTX: https://github.com/Stichting-MINIX-Rese ... _asm.S#L21

This, in turn, uses another macro SAVE_GP_REGS: https://github.com/Stichting-MINIX-Rese ... onst.h#L83

This macro saves EAX, ECX, EDX, EBX, ESI, and EDI: https://github.com/Stichting-MINIX-Rese ... .h#L51-L56

I am talking about the version 3.1 of minix, you re referring to 3.3 version which switches from segment based
multitasking to paging... we are not talking bout the same version of minix

The code I linked is in Minix 3.1.6: https://github.com/Stichting-MINIX-Rese ... .h#L50-L56

Prior that, pushad was used: https://github.com/Stichting-MINIX-Rese ... 386.s#L325

This save function is called by all the hardware interrupt handlers: https://github.com/Stichting-MINIX-Rese ... 386.s#L217

(The counterpart popad is found here: https://github.com/Stichting-MINIX-Rese ... 386.s#L401)

Further, support for 8086 segmentation was removed before 3.1 was released with the 3rd edition of OSDI.

Some of the history before then still exists in the converted git repository, though, and we can look at the 16-bit version of the interrupt handlers, where we find the general purpose registers being saved: https://github.com/Stichting-MINIX-Rese ... 35C20-L349

ITchimp wrote:what are the considerations for determining whether registers should be saved, and if so, which ones?

Hardware interrupts may happen any time they're enabled, so any registers the interrupt handler may modify must be saved. Software interrupts occur only when requested, so no registers need to be saved.

In practice, though, it's usually easier to save all registers when entering the interrupt handler. It simplifies things like debugging, where you might want to peek at the current state of an interrupted program, and it simplifies context switching since the program's entire context has already been saved. For software interrupts, it also removes the risk of leaking privileged data.

Octocontrabass wrote:In practice, though, it's usually easier to save all registers when entering the interrupt handler. It simplifies things like debugging, where you might want to peek at the current state of an interrupted program, and it simplifies context switching since the program's entire context has already been saved. For software interrupts, it also removes the risk of leaking privileged data.

Uniformity in what exactly the stack frame looks like also allows syscalls to use the same register structure as the rest of the kernel, and it allows syscalls and interrupts to share the return code. Because it turns out in a UNIX based OS, that is where you can do a few things.