Page 1 of 1
Developing an os, user mode, interrupts and syscalls
Posted: Tue Mar 19, 2019 3:43 pm
by lidorelias3
in my operating system I need to move to user mode. I know how to make the move but when I'm in user mode, there are no interrupts. so that means for example:
when I type something in keyboard, the buffer won't fill. so how do I suppose to make system calls to get char from keyboard if the buffer is empty?
If you have some example I can look on system calls and can tell me how I have to make it so I can be in user mode and still get input from keyboard, I would appreciate it.
Hope I make it clear.. Thanks for your help!
Re: Developing an os, user mode, interrupts and syscalls
Posted: Tue Mar 19, 2019 3:57 pm
by iansjack
What makes you think that interrupts don't happen when running user-mode tasks? The clue is in the name - "interrupt".
Re: Developing an os, user mode, interrupts and syscalls
Posted: Tue Mar 19, 2019 8:51 pm
by songziming
Interrupts also fire under user mode, as long as you set rflags.IF=1 before iret.
When process tries to read from an empty file, the process will change to pending state. And that process will be removed from ready queue. When other process or ISR write to the file, making that file not empty, the pending process can be wake up.
So when process calls getchar() while the stdin is empty, the process is actually pending, i.e. not running on CPU. When stdin becomes not empty, the process resumes and function getchar() returns.
Re: Developing an os, user mode, interrupts and syscalls
Posted: Wed Mar 20, 2019 6:04 am
by lidorelias3
iansjack wrote:What makes you think that interrupts don't happen when running user-mode tasks? The clue is in the name - "interrupt".
When you move to user mode you have the command "cli" which disable all interrupts
Re: Developing an os, user mode, interrupts and syscalls
Posted: Wed Mar 20, 2019 6:07 am
by lidorelias3
songziming wrote:Interrupts also fire under user mode, as long as you set rflags.IF=1 before iret.
When process tries to read from an empty file, the process will change to pending state. And that process will be removed from ready queue. When other process or ISR write to the file, making that file not empty, the pending process can be wake up.
So when process calls getchar() while the stdin is empty, the process is actually pending, i.e. not running on CPU. When stdin becomes not empty, the process resumes and function getchar() returns.
So when I have this code in c which move me to user mode:
Code: Select all
void switch_to_user_mode()
{
// Set up a stack structure for switching to user mode.
asm volatile(" \
cli; \
mov $0x23, %ax; \
mov %ax, %ds; \
mov %ax, %es; \
mov %ax, %fs; \
mov %ax, %gs; \
\
mov %esp, %eax; \
pushl $0x23; \
pushl %eax; \
pushf; \
pushl $0x1B; \
push $1f; \
iret; \
1: \
");
}
How do I set IF=1 So I still have interrupts in user mode and the system won't crash when I access the cpu?
Re: Developing an os, user mode, interrupts and syscalls
Posted: Wed Mar 20, 2019 6:51 am
by mallard
lidorelias3 wrote:
How do I set IF=1 So I still have interrupts in user mode and the system won't crash when I access the cpu?
Add an "orl $0x200, (%esp)" line after "pushf" in the assembly code. That will set IF in the flags value that is loaded by the IRET instruction.
I don't know what you mean by "access the cpu", all code "accesses" the CPU; where else would it run?
What do you think is the significance of the fact that the final instruction in the code to switch to usermode is "IRET"? That's the same instruction used to return from an interrupt. If that's how you enter usermode in first place, doesn't that give you a clue about what happens when you return from an interrupt that fired while the CPU was running in ring-3?
Re: Developing an os, user mode, interrupts and syscalls
Posted: Wed Mar 20, 2019 7:18 am
by iansjack
lidorelias3 wrote:iansjack wrote:What makes you think that interrupts don't happen when running user-mode tasks? The clue is in the name - "interrupt".
When you move to user mode you have the command "cli" which disable all interrupts
So - don't use that instruction, and don't disable interrupts.