A question on multitasking

[ethindp]

Hey all,
I've been reading this tutorial on multitasking and am a bit confused on the assembly interoperability. In the section entitled 'Step 1: Initialization and "Switch_to_task()"', the following ASM is given:

switch_to_task:

    ;Save previous task's state

    ;Notes:
    ;  For cdecl; EAX, ECX, and EDX are already saved by the caller and don't need to be saved again
    ;  EIP is already saved on the stack by the caller's "CALL" instruction
    ;  The task isn't able to change CR3 so it doesn't need to be saved
    ;  Segment registers are constants (while running kernel code) so they don't need to be saved

    push ebx
    push esi
    push edi
    push ebp

    mov edi,[current_task_TCB]    ;edi = address of the previous task's "thread control block"
    mov [edi+TCB.ESP],esp         ;Save ESP for previous task's kernel stack in the thread's TCB

    ;Load next task's state

    mov esi,[esp+(4+1)*4]         ;esi = address of the next task's "thread control block" (parameter passed on stack)
    mov [current_task_TCB],esi    ;Current task's TCB is the next task TCB

    mov esp,[esi+TCB.ESP]         ;Load ESP for next task's kernel stack from the thread's TCB
    mov eax,[esi+TCB.CR3]         ;eax = address of page directory for next task
    mov ebx,[esi+TCB.ESP0]        ;ebx = address for the top of the next task's kernel stack
    mov [TSS.ESP0],ebx            ;Adjust the ESP0 field in the TSS (used by CPU for for CPL=3 -> CPL=0 privilege level changes)
    mov ecx,cr3                   ;ecx = previous task's virtual address space

    cmp eax,ecx                   ;Does the virtual address space need to being changed?
    je .doneVAS                   ; no, virtual address space is the same, so don't reload it and cause TLB flushes
    mov cr3,eax                   ; yes, load the next task's virtual address space
.doneVAS:

    pop ebp
    pop edi
    pop esi
    pop ebx

    ret                           ;Load next task's EIP from its kernel stack

If we're in protected mode only, would I be correct in assuming that this assembly would work "out of the box" with the following declaration in Rust?

#[no_mangle]
extern "C" fn switch_to_task();

Whether or not this is correct, what would be the "proper" way of implementing the code in the above-linked tutorial in Rust in long mode? Would I be correct in assuming that just changing the registers will not work? Alternatively, is there a tutorial I can use to learn how to "properly" do multitasking in rust?

[phil-opp]

Maybe https://ryan-jacobs1.github.io/2019/12/29/threads.html helps?

[tsatke]

I would like to add my (working) implementation to that, built on that very article and EduOS' implementation.
https://github.com/martimos/kernel/blob/main/src/scheduler/switch.rs
Hope it helps.

[ethindp]

It... kinda helped, but his OS seems like its entirely different from yours and he doesn't cover as much, so I'm still kinda lost. Perhaps I'll focus on my filesystems stuff for now and await your post on multitasking?

…

On 1/22/20, Philipp Oppermann ***@***.***> wrote: Maybe https://ryan-jacobs1.github.io/2019/12/29/threads.html helps? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/phil-opp/blog_os/issues/718#issuecomment-577183084

-- Signed, Ethin D. Probst

[phil-opp]

I'm already working on it, but I expect that it will take some time.

[JohnDowson]

With 3rd edition under way, does it mean that the multitasking post will never arrive?